"Stripping" changesets from the past of a repository

[Martin Geisler]

"Jim Hewes" <jhewes at docucap.com> writes:

> I thought I had read that changeset IDs were calculated based on
> content from earlier revisions. If so, wouldn't it be possible when
> stripping out earlier revisions to base the new repository on an
> initial dummy revision that had a dummy changeset ID that caused all
> subsequent changesets IDs to be the same as they were before?

You would have to make a changeset and *assign* a fake ID to it. In
other words, you would have to tell Mercurial that it should pretend
that the first dummy changeset has SHA-1 value X, even though it really
has SHA-1 value Y.

Mercurial does not support this at the moment. If you were to fabricate
such a dummy changeset, then 'hg verify' would complain loudly. You're
in effect asking for a way to tell 'hg verify' that it should trust the
fake changeset hash value.

> The reason I ask about this is because I was thinking about having a
> build process which notes all the changeset IDs of each project when
> building a release. Then we don't have to always remember to add tags
> to revisions. The changeset IDs can act as tag. But then you could
> never strip off old revisions without messing that up.

Mercurial and all the other distributed revision control systems are
built on the expectation that you will not need to strip off old
history. When importing old history it can definitely make sense to
massage it by splitting a repository into several smaller repositories,
removing old binary cruft. But afterwards, you are expected to keep the
entire history locally.

So I suggest using the changeset IDs to identify the builds as you
propose above, but without trying to strip away old history.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial/attachments/20091117/2c3253f4/attachment.pgp>