Obsolete Markers and Phases

[Patrick Mézard]

Le 02/08/12 16:47, Scott Palmer a écrit :
> 
> On 2012-08-02, at 10:29 AM, Pierre-Yves David <pierre-yves.david at logilab.fr> 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.
> 
> Can you give us a typical use case?  I'm getting confused by this.  Since the introduction of "public" vs. "private" change sets, I thought rewriting history by actually mutating (or replacing) a changeset was now safe - because it was just a correction or alteration of local data that was not shared yet.

Phase helps you not mutate changesets which have been published.


Obsolete helps you describe how non-public changesets have been rewritten. You will not directly use this information but rewriting tools will. The middle of this post has an example of using evolve extension to rewrite a changeset in the middle of a changeset sequence:

  http://selenic.com/pipermail/mercurial-devel/2012-July/042948.html

Note, the "stabilize" call (similar to mq qpush for instance) use 3-way merge instead of patching since the changeset being rewritten is not destroyed but marked obsolete.

Obsolescence markers can also be used in collaborative settings where people work on the same sets of changes. See the end of the post referenced above for more details about this.

Also note, that all this stuff is still experimental :-)

--
Patrick Mézard