Obsolete Markers and Phases

[Todd Greer]

Rather than a lot of quoting, I'll summarize what I'm replying to:

	V: I want to be able to obsolete a public changeset.
	Pierre-Yves: Why?

Please forgive me if I've oversimplified.

I also want to be able to obsolete a public changeset, and I'll explain the motivating situations that have come up where I work:

The main repository for one of our groups should have only source files in it. I've had people not understand this and thus push large binaries, such as jar files. Obviously, I should have set up a system to prevent this, but for various reasons, that didn't happen, and those large binaries are there now. They've since been deleted, but they have still had the effect of making our repository much bigger than it should be, which makes cloning take longer, and wastes disk space. Currently, here are the ways I could deal with this:

1. Just accept the wasted space. We don't make new clones all that often and hard drives are cheap.
2. Strip those changesets from every repository everywhere.
3. Remove those changesets with an hg->hg convert, and make everyone re-clone.
4. Use the largefiles or kbfiles extension, (Kiln is our host, and they only support kbfiles)

We're currently just living with it, but I'd like to do better. Approaches 2 and 3 are quite inconvenient, and I've heard of enough issues with 4 that I'm uncomfortable with that approach. (Perhaps they've all been fixed--I haven't had time to investigate.)

If I could push a new changeset that marked those specific changesets as obsolete, such that they would not (by default) be received in a pull or clone, my problem would be gone. There should of course be a flag available to clone or pull and get obsolete changesets. If someone pushes a changeset based on an obsolete changeset, I'd be ok with an error that tells them to rebase.

Note that we haven't lost anything; no changeset has actually been modified, and the obsolete changsets can still be pulled with a flag to pull obsolete changesets.

Naturally, there are many workflows where this would be a bad idea, so obsoleting a public changeset should require a "--force" or something like that. It could even require an extension, as long as the obsolete marker, once there, would work as designed.

(BTW, another approach that would work for me would be the ability to strip a deleted file from a changeset. That would, of course actually modify public history, though it would at least be obvious, since you would have to get an error if you updated to a revision with the stripped file.)

Thanks,
Todd