On 03/30/2017 07:08 PM, Ryan McElroy wrote:
On 3/30/17 3:15 PM, Pierre-Yves David wrote:
[…]
I hope this long message help to clarify various concept. We have way
forward to reduce the use of stripping without abusing the
obsolescence concept in a way that will create issue for users. These
way forward are in reach and would not take too long to build.
For what it's worth, I find this essay pretty convincing: obsmarkers
have their use-case, they are lightly abused now (for temp-amend-commit)
but it probably makes sense to not abuse them further.
It sounds like an "internal" phase above "secret" would actually map
fairly well onto the temp-amend-commit, hidden shelves never meant to be
exchanged, aborted rebase, etc places.
Pierre-Yves, since you've thought about this a lot, does a phase here
make sense (note that I'm not saying a general hiding place like
"archive" phase, but just for internal nodes that we generally don't
want shown or exchanged, but are also not "technically obsolete".
Yes, phase could actually work when we talk about internal changesets.
They property makes is
* They are irrelevant to the users,
So, we do not care about preserving draft/secret phase,
* We should never-ever base anything on them,
So the inheritance to parent will not be an issue
* We should never-ever access them ever again,
So we can thrown them in the phase and never think about them again.
* They should never-ever leave the repository.
So their should not be any distributed related issue with them (and even
if they are hard copied, it is fine to never-ever mention them during
exchange.
* They never stop being internal-changesets
That one is a bit less "phasee", we would have to adds some boundary.
---
You I are right, given the property of internal changesets phases may be
a good pick for them.
I'll do a full review of the problem space and its possible solution, if
you want the summary skip to the end
Problem Space
=============
Possible approach
-----------------
Since introducing a new "internal" concept will requires a new
repository requirement. Lets discussion all options we have at hands.
1) dedicated 'internal' phases,
2) ad-hoc mechanism (lets says bytemap),
3) Something in changeset extra,
(If someone think about something else, let me know)
Internal changeset property
---------------------------
Now let us summarize their property of internal changesets
A) They are irrelevant to the users,
B) Nothing will be based on them,
C) Once done with their purpose, we should not need them again,
D) They never leave the repository,
E) They never stop being internal changesets,
Life Cycle of Internal Changeset
---------------------------------
And lets look at the life cycle of internal changeset we know:
amend
`````
1) transaction is open,
2) a temporary commit is created,
3) and used to build the result of the amend,
4) obsmarkers are created (between old and new),
5) temporary commit is disposed of (currently obsmarkers),
6) transaction is committed.
The commit is created and "hidden" in the same transaction. It is never
visible to anyone.
Actually, we would fully remove this change set with appropriate
in-memory-ctx capabilities.
histedit
````````
Scenario:
pick second-changeset
pick first-changeset
roll fourth changeset # the important part is the fold
pick third changeset
(Assuming single transaction for simplicity)
1) transaction is open,
2) <second-changeset> is rebased on base
(possible conflict and associated transaction open/close)
-> creates <final-first>,
3) <first-changeset> is rebased on the result
(possible conflict and associated transaction open/close)
-> creates <temporary-second>,
4) <fourth-changeset> is rebased on the result (no commit),
(possible conflict and associated transaction open/close)
5) result is folded in <temporary-second> as <final-second>
6) <third-changeset> is rebased on the result
(possible conflict and associated transaction open/close)
-> creates <final-third>,
7) transaction is committed.
Possible conflict during (4) will expose <temporary-second> as visible
to the user, part of the merge conflict and working directory parent.
shelve
``````
shelving:
1) transaction is open,
2) shelved change are committed,
3) commit is recorded as a shelve-changeset,
4) apply hidding on this shelve,
5) transaction is committed
unshelving (I might be wrong, I've not followed everything):
1) transaction is open
2) uncommitted changes are put in an temporary commit
*) access the shelve-changeset (somehow),
3) hg rebase -r <shelve> -d <tmp>
<) possible conflict resolution that requires transaction commit
>) possible transaction reopen (if conflict)
=) rebase complete
4) grab the result of the shelve and restore working copy parent
5) hide <tmp> and <rebased>
6) close transaction
Note: during possible rebase conflict, the "shelve" is currently visible
to the user. Can we change this ?
* At minimum, it needs to be at least visible to the "hg resolve
command". This is easy to achieve in all case.
* Having it visible seems valuable for the user experience.
conclusion in life cycle
````````````````````````
Internal:
visible -> not visible (rest there).
/ visible not visible
Additional note about shelve
-----------------------------
We could skip using the full rebase command and skip one of the
temporary changeset.
XXX skip the temp commit entirely
Only remain shelve changesets
- deleted shelve
It all happens in
Analysis of solution
====================
Phases
------
ad-hoc
------
changeset data
--------------
New space,
Need caching,
Conclusion
==========
* two phases (redefined + hard boundary)
* Still use extra.
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
