Tracking files and file-level operations

[Martin Geisler]

Chris Hecker <checker at d6.com> writes:

> Sorry, I meant as a first class operation. Lacking a "rename" or "mv"
> command is not what I meant. As far as I know, rename is implemented
> as a copy+delete in hg, like svn.

It is a first class operation whether you call it rename or copy+delete.
The important point is that Mercurial merges changes correctly across
renames and that it lets you follow history back across the rename.

> [...]
>
> The other rename related thing that appears to happen with hg, that I
> did test myself but have not investigated fully, was that if you
> rename a file, you get another copy in the repository, so if you
> rename a 10mb binary file, you get 20mb in the repo. With bzr, you get
> 20mb after the rename, but then if you pack or branch from that, it's
> back to 10mb (like it should be). I'd be interested to know if this is
> incorrect, since I couldn''t see a way to avoid it.

This problem is real, unfortunately. It is our Issue883. Basically,
Mercurial tracks the content of a given file name in a single file log.
When you rename a file, appropriate pointers are inserted to track the
rename, but a new file log is also created. File logs start with a
compressed snapshot of the file they track, so for an uncompressable
file, this costs you in storage space.


-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/