[Issue883] File/dir renames consume extra space in repository - alternative way of seen at it

jose miguel hernandez jmiguel.hdez at gmail.com
Thu Jan 7 11:17:49 CST 2010


---------- Forwarded message ----------
From: jose miguel hernandez <jmiguel.hdez at gmail.com>
Date: Mon, Jan 4, 2010 at 2:47 AM
Subject: [Issue883] File/dir renames consume extra space in repository
To: bugs at mercurial.selenic.com, mercurial-devel at selenic.com


Hello

I apologize if this was discussed before.

The problem of extra space is because  a new file is created on the
repo to track the future history of the renamed file. It repeats the
data to conserve history, More or less i believe...

I read here http://mercurial.selenic.com/wiki/RenameSpaceSavingPlan
that there is a lot of complications to handle revlogs as deltas (they
become not self contained)

is there a way to workaround this with another approach? for example

Instead of creating deltas, the space could be saved by
compressing/packing the related revlogs and keep them compressed
together.
It could be a new operation of the filelog (the filelog tracks the
renames?) to decompress/compress the revlogs.

As all the history is in one revlog, may be only one of them would
need to be uncompressed at a specific time.

I don't know if this makes sense but i was thinking that it might be
easier to implement it keeping backward compatibility as the revlogs
content will not change, so the hash do not need to change. It is just
one extra layer.

What do you think?

Regards


More information about the Mercurial mailing list