Status update on Obsolete Markers (Changeset Evolution)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri May 11 03:48:45 CDT 2012


On Fri, May 11, 2012 at 10:23:36AM +0200, Angel Ezquerra wrote:
> 
> one question I got when going through your documents the other day was
> how would some simple history rewritint operations affect the
> repository size.
> 
> In particular, imagine that I commit a revision adding a big file.
> Lets assume that the commit increases the size of the repo by exactly
> 10 MB. Imagine that the commit message had a typo that I wanted to
> correct. If commit --amend were modified to use the obsolete concept,
> and I used it to fix the typo, would that increase the size of the
> repo by an additional 10 MB, given that the new, corrected revision's
> parent would be the same parent as the original obsoleted revision? Or
> perhaps the obsolete concept relies on general delta?

No, the mercurial storage does not store a new whole version of the file as it
already exist in the repo it only store a delta. It is getting even better with
the general delta feature.

> Also, I did not see many references to the garbage collection strategy
> although perhaps I missed them...

The current garbage collection is manual: hg strip 'extinct()'

An automatic strategy based on extinct commit ages will probably be choosed later.

> Do you think it is too early for TortoiseHg to start adding support
> for this (e.g. to hide obsolete revisions by default)?

Mercurial 1.9 has an official way to hide changeset. supporting it would be a
great start. The opportunity of obsolete markers support for tortoisehg will
depends of the result of the sprint.

-- 
Pierre-Yves


More information about the Mercurial-devel mailing list