Completely baffled

[Paul Boddie]

On 06/12/11 11:28, Lester Caine wrote:
> Liam Routt wrote:
>> 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).
>
> Largefiles seems to be a red herring in this ...
>
> This is exactly to be expected activity IF the local changes had not
> been committed.

Perhaps apart from the lack of conflicts to be resolved, but yes, 
compulsive updating will lead to things being unnecessarily mixed together.

> I've managed to do much the same myself ...
> The one thing to remember that what is 'active' in the directory is the
> 'version' of the files that you select from hg, and this means that if
> you HAVE made any changes but not committed them ... they will be lost.
> Same as if you roll back to a different revision.

One has to remember to ask the question: if you update with local, 
uncommitted changes, what should you expect Mercurial to do about all 
those local changes? They have to "go" somewhere, and one place they 
can't go is back into the stored history.

Naturally, you can always pull changes without fearing the effect on 
your local, uncommitted changes. For people who have worked with CVS 
(and Subversion, I guess), this isn't necessarily obvious. It's only 
when you ask to have your working files updated that the mixing begins.

> With CVS/SVN setups, I was quite happy to keep local copies of a
> revision in a different directory, and this seems a safe way of working
> with dvcs as well. At least then you can compare builds.

Again, one has to ask oneself what the purpose of performing an update 
is. Is it to just see what other people have done? If so, you can 
obviously just pull and check the log, you can do a "hg cat" and see the 
other versions of a file, you can use hgweb to browse the other changes, 
and you can clone to get a separate working copy updated to work with 
those changes. Everything doesn't have to happen in the same directory.

> But the key
> thing that still irritates me is the still missing step of 'syncing'
> with the 'master' copy. In Eclipse I get a list of files changed, and
> can compare my own local changes with changes others have done
> potentially even in the same area of work. I can 'update' the local copy
> with just the lines I need and create a new local version ready to
> actually commit. This is something that is essential for SOME methods of
> working and the lack of that step HAS caused me to overwrite local work
> while I was learning a new process.

This sounds a bit like updating on a file-by-file basis or even a 
fragment-by-fragment basis. I've occasionally wanted to be able to split 
up diffs and apply parts of them separately, and I imagine that tools 
exist to do this, but I've been close on occasions to writing one myself 
(and for a very long time, too, remembering considering such things with 
CVS in about 1998).

> Shelve is a useful half way house for development versions, but keeping
> two or more directory trees in parallel works well with PHP development
> since I can 'run' the working copy at the same time as the development
> one and verify fixes. So I clone more than one local copy nowadays ...

Shelve and my own ad-hoc invocations of "hg diff > tmp.diff" are useful 
tricks, but I wouldn't want to be constrained to a single working 
directory and have to rely on them for everything.

Paul

P.S. Because it's you, Lester, I have to mention that I looked at that 
subrepository/subdirectory patch to hgweb recently, but I'm currently 
stuck on a weird test suite issue when it comes to testing hgweb that 
seems like an environment issue even though PATH and PYTHONPATH get set 
up properly. I'll see if I can't push this a bit further forward this week.