Obsolete Markers and Phases

[Greg Ward]

On 02 August 2012, Todd Greer said:
> 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)

<digression>
FWIW, switching an existing repo to use largefiles doesn't solve the
"OMG all my changeset IDs are different" problem you have in #3. If
your unwanted jar files were added at rev A, then all descendants of A
will be rewritten by lfconvert to become different changesets. So
everyone will have to reclone.

*And* you still have large binary files under source control, which is
just plain wrong (IMHO). I know game developers have a good use case
for largefiles, but Java developers and their jar file dependencies do
*not*. That's what Ivy is for. (Or Maven, if you must. ;-)
</digression>

> 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.

I think this is a slight abuse of obsolescence, but it's a neat idea.
You might have to write your own 10-line extension to actually do it
though.

       Greg
-- 
Greg Ward                                http://www.gerg.ca/
I am deeply CONCERNED and I want something GOOD for BREAKFAST!