obliterate functionality?

Patrick Mézard pmezard at gmail.com
Wed Mar 19 04:58:54 CDT 2008


Paul Moore a écrit :
> 
> Could I ask, at a technical level, if I have a file XXX in my
> repository, maybe added a few changes ago (possibly lots, on the case
> of the FreeBSD guys, but they can probably speak for themselves), how
> would I remove that file from my repository?
> 
> 1. What commands would I use? hg strip was mentioned, but that looks
> like it would also remove any other unrelated changes made after the
> addition, so presumably I'd need to do some cleanup as well - how
> would I do that?

strip removes revisions not files. In this case, the original issue should be: "How do I get rid of a revision somewhere in the repository" ?

Well, the idea is always the same : you clone the repository up to target revision parent, then import all descendants excluding target revision. You can do that by transplanting the changes, or with MQ.

Problems: 
1- it does not deal with merge automatically, so it can involve a lot of manual intervention
2- it assumes the repository can be rebuilt cleanly without the revision, otherwise you will have to deal with a lot of conflicts, manually.

Supporting a list of revisions to exclude in convert extension may solve these issues.

> Another option mentioned was hg convert, presumably
> I'd use a filemap to exclude the offending file, is there anything
> else I'd need to do (for example, if my repository was a private copy
> of a public project and I wanted to continue pulling after fixing my
> mistake)?

Rewriting history will change the identifiers of rewritten revisions and their descendants. When using convert, it's likely to change all revisions identifiers. So, the filtered repository will technically be a new one.

Convert extension can help with removing a path from a repository, which is a bit different from a file, but might be enough in most cases.

Problems:
- it can be very slow on repositories with large manifest. An issue is already opened for the netbeans one.

> 2. What implications might there be? For example, I mention above the
> case of a private copy of a public repository. Would I break the
> relationship between the two? Specifically, can it be made to *only*
> change the hashes of changesets from the introduction of file XXX
> onwards?

Currently it's hard to do that with convert. Recent "splicemap" option combined with an hypothetical "startrev" option for hg source may help, I have to dig a little more to be sure. convert.hg.startrev should be easy to implement, and will also provide a cheap history punching solution (updating revision identifiers though).

--
Patrick Mézard


More information about the Mercurial mailing list