Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Pierre-Yves David <pierre-yves.david <at> ens-lyon.org>
Subject: Re: Having more than three phases (was RFC: Phase UI (revset, phase command and others))
Newsgroups: gmane.comp.version-control.mercurial.devel
Date: Sunday 8th January 2012 15:27:16 UTC (over 4 years ago)
On Tue, Jan 03, 2012 at 12:52:56PM -0600, Matt Mackall wrote:
> ..except that every alternative I've seen proposed (obsoletion markers,
> dead heads) is MORE ill-suited. We made the rules, we can break them
> when appropriate. And I really don't see much wrong semantically with
> saying "these draft/secret changesets are to henceforth be ignored for
> log/push/pull and are subject to GC".

I insist, trash phase have too many issue to be of any use!

The big issue with using phase mechanism to mark changeset as dead is that
phase define set of node which are consistent regarding rules that are
problematic for the dead semantic. A golden semantic of phase are """all
descendant of a changeset in phase X have the same property that this
changeset""". We **can not** alter this:

    (1) We created phase for this exact semantic and we need it for all
other usage.
    (2) The way phase are store and exchanged rely on this [1].

Having a trash phase means that a Y changeset children of X may be seen
dead
"by mistake" just because X was marked as dead. This is very problematic if
X
is added **after** the data than X is dead was created.

Small local example bellow:

    $ hg pull
    Getting changeset "X"
    You look "X" and decide it's a silly changeset
    $ hg trash "X"
    Getting patch-y.diff from your mailbox
    patch-y.diff is a nice bugfix and you want it
    by chance, patch-y.diff have been created above "X"
    $ hg import --exact patch-y.diff
    As "Y" is a descendant of "X", "Y" is trashed too!

This example highlight that phase are not very well suited to store "dead"
information.

We may have dedicated logic that detect new changesets is added on top of
trashed one and handle this situation. But phase for dead still have two
major
issue!

1)  It prevents any sane synchronisation of this trash phase with the
outside.
As phase only store un-versionned data, you have no way to know if the
trash phase information were created before or after a changeset was
committed.
This means that you can't decide if the trash data really applies to
changeset
when you transfers it.

2) Adding non-trashed changeset on top on trashed changeset means moving
the
boundary and loosing the information that the parents trashed changeset are
"not welcome in the final history".

To conclusion about trash phase:

    * You can not safely exchange data about "dead" changeset through
phase.
      Loosing most of point of having this data.

    * Safely using phase locally mean loosing the "dead" information
whenever
      there is a conflict.

Moreover, the obsolete marker proposal[2] **are not ill suited**. It does
have…

…the same interesting properties than phase:

    * It is not stored in the history,
    * It can be exchanged over the wire through pushkey independently than
actual changeset.

…several additional properties:

    * There is no risk to kill descendants by mistake as each obsoleted
changeset are explicitly recorded.
    * Inconsistency and conflict can be easily resolved because the marker
store the details of why a changeset was set "dead".


-- 
Pierre-Yves David

[1] Whenever we store roots or heads.
[2] http://mercurial.selenic.com/wiki/MutableHG
_______________________________________________
Mercurial-devel mailing list
[email protected]
http://selenic.com/mailman/listinfo/mercurial-devel
 
CD: 3ms