Obsolete Markers and Phases

[v]

Pierre-Yves David wrote
> 
> On Thu, Aug 02, 2012 at 07:26:21AM -0700, v wrote:
>> 
>> Pierre-Yves David wrote
>> > 
>> > On Thu, Aug 02, 2012 at 07:20:53AM -0700, v wrote:
>> >> http://mercurial.selenic.com/wiki/ChangesetsObsolescence and hg help
>> say
>> >> that
>> >> obsolescence can't/shouldn't be used for public changesets.
>> >> 
>> >> Isn't this the whole point?
>> > 
>> > Golden rule:
>> > 
>> >     The whole point of **public** changeset is to be immutable.
>> > 
>> 
>> Does obsolescence mutate changesets?
> 
> Obsolescence marker track changesets mutation.
> 
> Public changeset will refuse to be Mutated.
> 
> Note: Mutation of a changeset is actually the writting a whole new
> changeset.
>       As per DVCS design.
> 

I realise that my last 10 (published) changesets were barking up the wrong
tree, so I decide to abandon them. I update to -10, continue committing,
then publish the new changesets.

If I do this with git, the old changesets will disappear from the regular
UI, along with anything committed on top of them, and will become candidates
for garbage collection after a month. This creates a race condition,
although with care, the good-on-top-of-bad commits can be rebased onto the
new head.

If I do this with mercurial, both heads will remain visible in the
repository, unless I can send a message to every repository owner to strip
the bad changesets (which is what Bitbucket tries to do). Only the moving
tip will indicate which head is "current".

Obsolescence could bring the best of both worlds to mercurial if implemented
for public changesets. My bad changesets will be explicitly succeeded by the
good changesets, anything committed on top of the bad changesets will remain
as before, and the obsolescence information will be transferred with
push/pull.



--
View this message in context: http://mercurial.808500.n3.nabble.com/Obsolete-Markers-and-Phases-tp3991397p3991408.html
Sent from the General mailing list archive at Nabble.com.