question regarding mercurial

[Mark Williamson]

> On 04.03.2008 19:22, Mohit Aron wrote:
> > 2) It seems one can just modify files without telling mercurial about
> > the intent to do so. And then 'hg status' has to figure out what all is
> > being modified - possibly by doing a 'stat' on each file in the
> > repository. While this might be ok for a local disk, this is terrible
> > for workspaces on NFS.

<snip>

> A "hg edit" is very unlikely to happen anyway as that design decision
> has been made.

I imagine somebody could write an "hg edit" extension that would take care of 
this behaviour.

The problem is that if you're on a slow filesystem link, hg will waste lots of 
time doing expensive stats over the network in order to determine what 
changed...

If you skip the stage of running "hg status" and instead just run:
hg commit <file1> <file2>
etc then you can avoid this.  It just means you have to remember what files 
were changed, rather than letting hg do it for you - which isn't as user 
friendly, I'll agree.

If you don't want hg to bother stat-ing unknown files, you could try something 
like:
hg status -mard
to show only modified, added, removed and deleted files - all files that hg 
already knows about.  Use a subset of these flags if you're only interested 
in a certain class of files.

You should consider adding entries to your .hgignore file.  You can ignore 
specific patterns in there.  If a directory subtree matches that pattern then 
hg /won't recurse in there at all/ when looking for unknown files.  This can 
make things massively faster, particularly if you have a large build tree in 
the repository that you don't want to track.

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)