Why are renames so expensive?

[Jeff Schiller]

$ hg init
$ du -k . | sort -nr | head -1
8 ./.hg
$ cp ~/some-pic.jpg .
$ du -k . | sort -nr | head -1
3248 .
$ hg add some-pic.jpg
$ hg ci -m "Add photo"
$ du -k . | sort -nr | head -1
6516 .

At this point, the repo now takes about double hte size of the photo.
So far this is what git and bzr do as well.

$ hg rename some-pic.jpg photo.jpg
$ hg ci -m "Rename photo"
$ du -k . | sort -nr | head -1
9756 .

Now the repo takes about triple the size of the photo. git and bzr do
not do this, they seem to do a logical move.

Why does hg take this approach? I see no logical reason why a move or
copy should not be only a fixed delta cost to the repo.

Thanks,
Jeff
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial

[Wagner Bruna]

Hello,

Jeff Schiller wrote:
> $ hg init
> $ du -k . | sort -nr | head -1
> 8 ./.hg
> $ cp ~/some-pic.jpg .
> $ du -k . | sort -nr | head -1
> 3248 .
> $ hg add some-pic.jpg
> $ hg ci -m "Add photo"
> $ du -k . | sort -nr | head -1
> 6516 .
>
> At this point, the repo now takes about double hte size of the photo.
> So far this is what git and bzr do as well.
>
> $ hg rename some-pic.jpg photo.jpg
> $ hg ci -m "Rename photo"
> $ du -k . | sort -nr | head -1
> 9756 .
>
> Now the repo takes about triple the size of the photo. git and bzr do
> not do this, they seem to do a logical move.
>
> Why does hg take this approach? I see no logical reason why a move or
> copy should not be only a fixed delta cost to the repo.

This is a known issue; take a look at

http://mercurial.selenic.com/wiki/RenameSpaceSavingPlan

for some details.

Regards,
Wagner

[Jeff Schiller]

Thanks Wagner. I've subscribed to be Nosy about that bug now :) Do
you happen to have any updates to it?

Also, I'm a little new to Mercurial, until I can get cheap
renames/moves, I'm thinking I'd like to purge old revisions back to a
certain time/revision (i.e. sort of 'rebase' an entire repository and
permanently get rid of history). Is there a way to do this easily?

For instance, a command to run to throw out all revisions that are a
year or more old? or something equivalently workable...

I know I can just create a completely new repo, but that tosses out
ALL history, obviously.

Thanks again,
Jeff

[Sune Foldager]

On 20-02-2010 00:12, Jeff Schiller wrote:
> Thanks Wagner. I've subscribed to be Nosy about that bug now :) Do
> you happen to have any updates to it?

I am currently working on it (most of the work has been done already by
someone else, and just needs to be completed). Along with some other
enhancements, we hope to get it into the tree soon, but I can't make
absolute promises.

The good news is that an existing repository should be able to be
"upgraded" to a light-weight copy version simply by cloning it (with
--pull).

>>> Why does hg take this approach? I see no logical reason why a move or
>>> copy should not be only a fixed delta cost to the repo.

"Logical reason" is a pretty broad term. Implementation reasons, I
suppose :)

/Sune