1

So, recently, I have rearranged the files in my company's main code repo so it is more sorted and such. This involved moving almost every file to a different location in the repository and that was the only change that was made. This resulted in the .hg folder growing from 16 gb to 21 gb (+ 5 gb) with just one revision.

Why does this happen and is there a way I can avoid it and make that revision less large? Yes, I did use the move command and yes, I have searched Google and I haven't gotten any results to explain this or provide a way to reduce the size of the repo beyond splitting it into multiple ones (which would still likely be the same size).

1 Answer 1

3

If I understand the hg architecture correctly —

Mercurial's history storage format uses a single "revlog" per file; each new version is appended to the same log file. (For example, all versions of "hello.c" are kept in ".hg/store/data/hello.c.i".) Nearby revisions in the same revlog are delta-compressed to save space (sharing data between revisions of the same file).

However, the format still does not have any mechanism to share identical data between revlogs belonging to different files. As a result, if you previously had some data in file A and now have it in file B, then it has to be stored at least once in full in each file's revlog. You can see some progress regarding this in the Bugzilla thread #883.

Note that hg move does not rewrite history. Even after you rename file A to file B, all previous revisions will still refer to it as file A, so the repository must continue to have revlogs for both files A and B (one containing the old revisions, the other containing new ones).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .