Completely baffled

[Na'Tosha Bard]

2011/12/5 Na'Tosha Bard <natosha at unity3d.com>

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

Correction - this should say "which generally means people are *not*
pulling/updating when they have a dirty working copy.

Cheers,
Na'Tosha


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


-- 
*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://lists.mercurial-scm.org/pipermail/mercurial/attachments/20111205/09686323/attachment-0002.html>