Completely baffled

[Na'Tosha Bard]

2011/12/5 Liam Routt <liam.routt at mediasaints.com>

> 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).
>

My team uses Largefiles heavily and we have not seen this.  Are you saying
that he had a dirty working copy (with a change to a largefile) and then
did a pull+update, which reverted his changes?  We have a commit-often
policy, which generally means people are pulling/updating when they have a
dirty working copy, which might be why, if this is a bug, I have not seen
it before.

If you can reproduce it with a valid test case, please file a bug on
http://mercurial.selenic.com/bts and I'll fix it.  This issue is a
wonderful example of how to report a bug:
http://mercurial.selenic.com/bts/issue3093

Cheers,
Na'Tosha


> 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
>>
> ______________________________**_________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/**listinfo/mercurial<http://selenic.com/mailman/listinfo/mercurial>
>



-- 
*Na'Tosha Bard*
Build & Infrastructure Developer | Unity Technologies

*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20111205/3ca5ec82/attachment.html>