Completely baffled

[Liam Routt]

Just as a followup, we managed to lose the last two days of work by one 
of our developers today with Mercurial, which really hurts.

Prior to doing the checkin of the work he'd done, he did a pull + 
update. During the course of that, with no prompts of any sort, the 
largefile system replaced the key flash file he'd been editing with the 
version from before his changes. No one else has changed the file for 
several days, so it was not a case of incoming changes which needed to 
be merged (and he was not prompted to resolve any conflicts), his 
changed file was simply replaced with the "current" version as part of 
the pull + update, and as a result of course disappeared from the list 
of files to be committed (as we have seen before).

We have been unable to locate the file he was working on in any way on 
the disk, which is a shame. We have only the old version which replaced it.

While this is the most serious instance of this we have had, it is 
entirely consistent with the problems we've seen with the largefiles 
system, at least the way we've been using it, from the start. This is a 
huge disappointment for me. I was close to converting the repositories 
this weekend to remove the largefiles, but decided that we could ride it 
out until our delivery (which was today, and is now tomorrow, if we are 
lucky).

I'd love to know what we have done wrong (other than using a system that 
was not fully tested - which is our look out, of course), if anyone can 
help us.

(It might be worth noting that I was asked before whether we had the 
same issues using the command line version as the GUI. I haven't had 
time to do many tests, but the ones I did run were identical regardless 
of which interface we used, assuming we did the same things.)

Take care,

Liam Routt
Media Saints

On 5/12/2011 11:19 AM, Liam Routt wrote:
> We adopted Mercurial a couple of weeks back, to see us through to the
> delivery of our project (today). We are using TortoiseHg 2.2 on a
> variety of machines, and a server running the equivalent Mercurial 2.0.
> We have many largefiles in our projects, which were converted from bzr
> and then converted using lgconvert with a pattern which seemed to
> correctly have identified all the files we intended.
>
> We're finding that many of the machines in the office are not
> up-to-date, even after we do a pull followed by an update (which the GUI
> allows us to force).
>
> Our configuration is roughly CVS-like:
>
>
> Server (linux)
> |
> +----------+-----+--------+----------+
> | | | |
> Win client Win client Win client Win client
>
> Each of the clients is making changes to their workspace and
> occasionally doing a commit followed by a push to the server. In order
> to avoid multiple heads, we are trying to do a synchronize (pull +
> update) before doing the commit. We have a precommit hook which warns us
> if there are incoming changes when we try to do a commit, prompting us
> to do a pull and update.
>
> Perhaps all of this works. It acts as though it does.
>
> I've previously mentioned that I was experiencing situations where doing
> a pull + update was removing entries from a commit - ie. we are in the
> process of doing a commit which has a number of files (largefiles) in
> it, when we do the pull + update some of the files (largefiles) are no
> longer listed in the commit, and as far as I can tell are unable to be
> commited and pushed on to the repository.
>
> That was the only problem I thought we had, but now we are realizing
> that several of the clients do not have the most recent files in their
> workspaces, after doing a pull + update. These are clients who have not
> changed these files locally. There are no pending merges that we can see.
>
> It is possible, though, that these clients have not being doing a pull +
> update as often as the clients which seem to be up to date, but I doubt
> that should be necessary.
>
> An additional problem is that we've been unable to do a clone of the
> current repository, encountering a seemingly fatal problem with a
> largefile which we are told cannot be found.
>
> Running a verify on the server's version of the repository shows no
> problems.
>
> In order to clone, I am now making a copy of the current workspace and
> repository from one known good machine and putting that on to any client
> that needs the current version. That seems to work, at least for a
> while, but doesn't help in working out what is going wrong, nor has it
> helped us to reacquire confidence that each system is up-to-date, which
> at this final stage of our project is critical to locating problems and
> getting them fixed.
>
>
>
> I know there is likely precious little anyone can suggest to help us in
> the short-term, and that situations like this are almost impossible to
> assist with unless a more complete report is given (which I don't have
> the time to make, given where we are in our project). I've written this
> on the off-chance that someone has a bolt-from-the-blue suggestion ("why
> aren't you doing X?").
>
>
> Take care,
>
> Liam Routt
> Media Saints