Obsolete Markers and Phases

[Benjamin Fritz]

On Mon, Aug 6, 2012 at 12:39 PM, v <voldermort at hotmail.com> wrote:
>
> Pierre-Yves David wrote
>>
>> - They do not store information about potential replacement. (And if they
>> do, it'll be less convenient)
>>
>
> If the abandoned changesets have indeed been replaced with different
> changesets, this information ought to be as convenient as for obsolete
> changesets?
>
>

It seems to me that the difference between abandoned and obsolete
changesets is mostly in their intended use. Maybe I'm way off-base
here, but it sounds like:

"Obsolete" is for changesets which:
1. Were never intended to go public as-is (proof-of-concept patches,
experimental fixes, "commit now and clean up later" workflow, etc.)
2. Got pushed/pulled with some other repository or person on a limited
basis (e.g. "Hey, can you take a look at this change to see if it does
what you had in mind?" or "Man, if I had this code on my laptop I
could finish it at home instead of staying late at work!")
3. Are now refactored, or determined to be a bad idea, or rebased, or
whatever, and therefore aren't supposed to be part of anybody's
history.

"Abandoned" is for changesets which:
1. Were under active public development or otherwise intentionally
released "into the wild"
2. Had a good deal of work done on them
3. Were later determined to be a bad idea, replaced with an alternate
or competing implementation, or made pointless by a better solution to
the problem.

"Obsolete" seems like it might get more use by individuals or small
tight-knit teams who like to commit frequently and back up their work
in multiple repositories but also like to push "clean" history to
their public repository.

"Abandoned" seems like it might get more use from large or widely
distributed teams working on big features together, or for when a team
decides to implement something multiple ways to later pick the best
method when "best" can't readily be determined before implementation.

Again, if I understand the intent of the features correctly, it would mean:
1. "Obsolete" changesets should pretty much never get pulled or used
as a parent for another changeset (at least not intentionally); you
should pretend they don't exist because they either never should have
existed or have been replaced by a "clean" version.
2. "Abandoned" changesets might be part of a "bad idea" or "alternate
implementation" that is perfectly fine to resurrect later if the
situation changes. These might be interesting to some people (mostly
for historical reasons) but the average use need not pay them any
attention.