On 04/06/2017 02:46 AM, Jun Wu wrote:
obsstore-based hidden is broken by design, since it cannot unhide commits:
$ hg export . > patch.txt
$ hg prune . # could also be done by pulling obsmarkers from a remote
# peer, or it could be amend / metaedit etc.
$ hg import --exact --bypass patch.txt # cannot really import the patch
The case you describe above work as intended.
By using "hg prune ." you globally marks the changeset as an undesirable
dead-end (obsolete-pruned)[1]. re-obtaining the same changesets in this
repository or in another will not affect this global state. We are just
adding global informations together:
The changeset exists + a prune marker exists == this changeset is
obsolete.
This global state is a critical part of changeset evolution, and the
visibility rules computed from obsolescence are fully parts of this
state[2].
The uses can change their mind and bring the changes back to life. We
currently have a basic command `hg touch` doing so (more useful friendly
alternative are in project),
To "bring" this changeset back to life, new information needs to be
added. In addition, currently the changesets is "brought back" with a
different hash. A new changeset node "NEW" and an obsolescence markers
marking "NEW as a replacement for OLD" are created.
This hash changes is necessary as the current implementation of
evolution relies on "monotonic rewrite"[3] that ensure different actions
will always creates a new nodes. These monotonic rewrites comes with
many useful property to simplify the problems evolution as to solves[4].
The hash change is not the best thing from user experience
perspective, but it practice the impact is very minor[5].
They -might- be ways to introduce new mechanism that would lift the need
for monotonic rewrites while still solving the same problems. So far,
such mechanism are unknown and concrete plan does not exists. The
current roadmap focus on being able to ship evolve to all with monotonic
rewrites.
[1]
https://www.mercurial-scm.org/wiki/CEDConcept#Obsolescence_markers_semantic
[2] https://www.mercurial-scm.org/wiki/CEDConcept#Global_State
[3] https://www.mercurial-scm.org/wiki/CEDConcept#Monotonic_rewrite
[4] https://www.mercurial-scm.org/wiki/CEDConcept#Problem_this_Easily_Solve
[5] https://www.mercurial-scm.org/wiki/CEDConcept#User_Impact
The new ui requires the ability to unhide commits. So hidden-ness should not
be affected by obsstore. That means extra work is needed to make sure
commands like amend also write to the new hidden store if they write
obsolete markers to hide commits today.
I think most people agree on this. I just want to make it clear as
Pierre-Yves does not mention this aspect in his long text.
So far, I'm not seen a rational for hash-preservation been a
-requirement- nor a group of people agreeing it is a -requirement-.
Sure it would be nice, but "nice" is different from -required-.
This is probably a core point we need to iron out in this discussion.
On 04/05/2017 11:22 PM, Jun Wu wrote:
[…]
There are some questions that I'm waiting for your answers:
- Define "user intention" about adding a obsmarker formally [1]
I've started formally writing some of the evolution concept.
Does this section fits your need:
*
https://www.mercurial-scm.org/wiki/CEDConcept#obs-marker:_General_Principle
- Why "an unified hidden store" does not work [2]
Changeset evolution is based on a global state created by the
obsolescence markers. The hiding from evolution is a computed property
of this global state. It -cannot- be delegated to an independent, local-
only, user manipulable hiding mechanism. Hiding from obsolescence
markers is a "static" property that -must- remains independent from the
local hiding mechanism (See previous [2] for details).
Local-hiding has its own merit and would help various usecase. The two
mechanism can perfectly exists side by side.
On 04/05/2017 11:50 PM, Jun Wu wrote:
I think it's unnecessary to have "internal changeset" concept separated from
the general-purposed hidden.
They are some case where having explicit internal changeset are useful:
Case 1: looking at hidden changeset,
When the user want to look or query the set of hidden changeset (eg:
user remember he hided something he now needs). Commands will be run to
see `hg log --hidden` or even select `hg log --hidden --rev 'hidden()
and file('foo/bar') and date(-7)'`.
Without an internal changesets, this command will display and select
internal changesets that are irrelevant/scary to the user. Having
explicit "internal" changesets allow to filter them out of such search
from the user.
Case 2: History of hiding
I can expect user to request a command displaying the history of what
they hide/archived[6]. They could use it to undo things. Without
distinction between archived and real changesets, this history will list
hiding and changesets from internal operation, surprising/confusing the
user and polluting the output.
If we have explicit "internal" changeset we can clean up these
output. If make them life in their own way (phases), we do not even have
do deal with them when building such UI.
How do you plan to handle theses cases ?
But if the community do decide to implement the
internal changeset concept, I think that could be doable, but it should be
done in the new non-phase store, instead of adding a new phase.
Therefore, I'm -1 on adding a new phase in all cases, since there are better
choices.
Can you elaborate on why think a non-phase approach is better to
implement an "internal" concept.
Cheers,
--
Pierre-Yves David
[6] I like archived as a word for this.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
