Mercurial > evolve
changeset 228:5a17c0d41a00
proof-read documentation and docstrings
| author | Nicolas Chauvat <nicolas.chauvat@logilab.fr> |
|---|---|
| date | Wed, 09 May 2012 14:24:56 +0200 |
| parents | abe52cf492ee |
| children | 681e25e5d83a |
| files | docs/evolve-faq.rst docs/from-mq.rst docs/index.rst docs/obs-concept.rst docs/obs-implementation.rst docs/tutorials/tutorial.t docs/unstability.rst hgext/evolve.py hgext/obsolete.py hgext/qsync.py |
| diffstat | 10 files changed, 178 insertions(+), 279 deletions(-) [+] |
line wrap: on
line diff
--- a/docs/evolve-faq.rst Wed May 09 13:08:46 2012 +0200 +++ b/docs/evolve-faq.rst Wed May 09 14:24:56 2012 +0200 @@ -3,6 +3,8 @@ Evolve How To --------------------------------------------------------------------- + + Add a changeset: ``commit`` ------------------------------------------------------------ @@ -11,9 +13,10 @@ Rewrite a changeset: ``amend`` ------------------------------------------------------------ -A dedicated command ``hg amend`` is added by the extension. It writes a new -changeset combining working-directory parent changes and parent. It will work on -any `draft` or `secret` changeset. It will not work on `public` changesets. +A new command ``hg amend`` is added by the extension. It writes a new +changeset combining working-directory parent changes and parent. It +will work on any `draft` or `secret` changeset. It will not work on +`public` changesets. To understand what the result of amend will be I use the two following aliases [#]_:: @@ -30,15 +33,13 @@ This command can even be invoked on changesets with children (provided none is public) ! -.. note:: The amend command is very similar to mq's ``qrefresh``, a ``refresh`` +.. note:: the amend command is very similar to mq's ``qrefresh``, a ``refresh`` alias for amend is also available. But note that contrary to ``qrefresh``, ``amend`` does not exclude changes on file not specified on the command line. XXX add idank example -.. warning:: The `hg commit --amend` switch does **not** lay obsolete marker - down yet. You should always prefer the dedicated command. .. [#] (added by enable.sh) @@ -51,13 +52,13 @@ branches onto the current branch". The graft command has been altered to allow the creation of an -obsolete marker between both the result cset and its source +obsolete marker indicating both the result cset and its source (actually recording changeset movements). This is achieved using a new flag `-O` (or `old-obsolete`) [#]_. -XXX Need a few examples here. +XXX example .. warning:: when using graft --continue after conflict resolution you **MUST** pass `-O` or `-o` flag again because they are not saved for now @@ -67,17 +68,13 @@ abusive. But this was very convenient for experimental purposes. This will likely change in non experimental release. - Delete a changeset: ``kill`` ------------------------------------------------------------ -A new ``kill``[#]_ command allows removing a changeset. +A new ``kill`` command allows removing a changeset. Just use ``hg kill <some-rev>``. -.. [#] `kill` is a terrible name. **NEVER** forget to add `hg` in front of it - until we find a better name. - Moving within the history: ``up`` ``gdown`` and ``gup`` ------------------------------------------------------------ @@ -94,16 +91,12 @@ Collapse changesets: ``amend`` ------------------------------------------------------------ -You can use amend -c to collapse multiple changeset in a single one. - - -.. note:: This is a terrible UI. `hg collapse` should be ported to obsolete - marker for this purpose. +you can use amend -c to collapse multiple changeset in a single one. Split a changeset ----------------------- -There is no official command to split a changeset [#]_ . However is it easily achieved +There is no official command to split a changeset. However is it easily achieved by manual operation:: ### you want to split changeset A: 42 @@ -119,8 +112,6 @@ # current changeset (.) and previous one (.^) replace A (42) $ hg kill --new . --new .^ 42 -.. [#] Yet - Update my current work in progess after a pull ---------------------------------------------- @@ -128,14 +119,10 @@ Whenever you are working on some changesets, it is more likely that a pull will, eventually, import new changesets in your tree. -And it is likely that you will want your work in progress changesets to be +And it is likely that you will want your work in progress changsets to be rebased on the top of this newly imported subtree. -Doing so is only a matter of rebasing. Rebase have been wrapped to lay obsolete -marker down. - - -XXX Add an example here. +Doing so is only a matter of rebasing. @@ -144,7 +131,7 @@ You can still use rebase to move a whole segment of the changeset graph together. -.. warning:: Beware that rebasing changesets already obsolete by others will result in +.. warning:: Beware that rebasing obsolete changesets will result in conflicting versions of the changesets. Stabilize history: ``stabilize`` @@ -159,17 +146,15 @@ newest version. This is not done automatically to avoid the proliferation of useless hidden changesets. -.. warning:: - - * ``hg stabilize`` have no --continue to use after conflict +.. warning:: ``hg stabilize`` have no --continue to use after conflict resolution - * stabilization does not handle deletion yet. +.. warning:: stabilization does not handle deletion yet. - * stabilization does not handle rewriting conflict yet. +.. warning:: obsolete currently relies on changesets in secret phase + to avoid exchanging obsolete and unstable changesets. - * obsolete currently relies on changesets in secret phase - to avoid exchanging extinct() changesets. + XXX details issue here Fix my history afterward: ``kill -n`` @@ -178,17 +163,18 @@ Sometimes you need to create an obsolete marker by hand. This may happen when upstream has applied some of your patches for example. -You can use ``hg kill --new <new-changeset> <old-changeset>`` to add obsolete +you can use ``hg kill --new <new-changeset> <old-changeset>`` to add obsolete marker. -Export to mq: ``qsync`` +Export to mq: ``synchronize`` ------------------------------------------------------------ -Another extension allows to export mutable changeset to mq. See the -`enable-qsync.sh` to enable it and read module documentation for details. +Another extension allows to export. -If you do not work at Logilab. You probably do not need it. +View change to your file +------------------------------------------------------------ +Another extension allows to export. View diff from the last amend ------------------------------------------------------------ @@ -199,9 +185,6 @@ [alias] odiff = diff --rev 'limit(obsparents(.),1)' --rev . -The qt viewer `hgview` displays obsolete data and allows to see diff again -obsolete parent. - View obsolete markers ------------------------------------------------------------ @@ -212,9 +195,22 @@ +Important Note +===================================================================== + +View change to your file +------------------------------------------------------------ + +Extinct changesets are hidden using the *hidden* feature of mercurial. + +Only ``hg log`` and ``hgview`` support it. ``hg glog`` or other visual viewer don't. + + + +
--- a/docs/from-mq.rst Wed May 09 13:08:46 2012 +0200 +++ b/docs/from-mq.rst Wed May 09 14:24:56 2012 +0200 @@ -5,23 +5,21 @@ Cheat sheet ------------- -:: - - ============================== ============================================ - mq command new equivalent - ============================== ============================================ +============================== ============================================ +mq command new equivalent +============================== ============================================ - qseries ``log`` - qnew ``commit`` - qrefresh ``amend`` - qpop ``update`` or ``qdown`` - qpush ``update`` or ``gup`` sometimes ``stabilize`` - qrm ``kill`` - qfold ``amend -c`` (for now, ``collapse`` soon) - qdiff ``odiff`` +qseries ``log`` +qnew ``commit`` +qrefresh ``amend`` +qpop ``update`` or ``qdown`` +qpush ``update`` or ``gup`` sometimes ``stabilize`` +qrm ``kill`` +qfold ``amend -c`` (for now, ``collapse`` soon) +qdiff ``odiff`` - qfinish -- - qimport -- +qfinish -- +qimport -- Replacement details @@ -34,7 +32,9 @@ You can use the standard log to display them. You can use the phase revset to display unfinished business only and templates to have the same kind of compact -output qseries has.:: +output qseries has. + +This will result in something like that:: [alias] wip = log -r 'not public()' --template='{rev}:{node|short} {desc|firstline}\n' @@ -42,7 +42,7 @@ hg qnew ```````` -With evolve you handle standard changesets without additional overlay. +With evolve you handle standard changesets without an additional overlay. Standard changeset are created using hg commit as usual.:: @@ -63,8 +63,8 @@ hg qref ```````` -A dedicated command from evolve will allow you to rewrite the changeset you are -currently on.:: +A new command from evolution will allow you to rewrite the changeset you are +currently on. just call: $ hg amend @@ -80,19 +80,16 @@ $ hg record babar.py $ hg amend -c .^ # .^ refer to "working directoy parent, here 'feature A' -.. warning:: `hg commit --amend` from Mercurial 2.2 does not lay obsolet marker yet and should - **not** be used. - note: refresh is an alias for amend hg qpop ````````` -the following command emulate the behavior of hg qpop: +the following command emule the behavior of hg qpop: $ hg gdown -If you need to go back to an arbitrary commit you can just use: +If you need to go back to an arbitrary commit you can just us: $ hg update @@ -103,10 +100,10 @@ ```````` When you rewrite changesets, descendants of rewritten changesets are marked as -"unstable". You need to rewrite them on top of the new version of their +"out of sync". You need to rewrite them on top of the new version of their ancestor. -The evolution extension adds a command to rewrite "unstable" changesets:: +The evolution extension adds a command to rewrite the "out of sync" changesets::: $ hg stabilize @@ -125,7 +122,7 @@ hg qrm ``````` -evolution introduce a new command to mark a changeset as "obsolete".:: +evolution introduce a new command to mark a changeset as "not wanted anymore".:: $ hg kill <revset> @@ -135,8 +132,8 @@ :: - $ hg up <top-most-changeset> - $ amend --edit -c <bottom-most-changeset> + $ hg up <top changeset> + $ amend --edit -c <bottom changeset> or later:: @@ -155,7 +152,7 @@ hg qfinish and hg qimport ```````````````````````````` -Are not necessary anymore. If you want to control exchange and mutability of +Is not necessary anymore. If you want to control exchange and mutability of changesets, see the phase feature
--- a/docs/index.rst Wed May 09 13:08:46 2012 +0200 +++ b/docs/index.rst Wed May 09 14:24:56 2012 +0200 @@ -6,7 +6,8 @@ Here are various Materials on planned improvement to mercurial regarding rewriting history. -First read about what challenge arise while rewriting history and how we plan to solve them once and for all. +First read about what challenge arise while rewriting history and how we plan to +solve them once and for all. .. toctree:: :maxdepth: 2 @@ -16,22 +17,20 @@ The effort is splits in two parts: * The **obsolete marker** concept aims to provide and alternative to ``strip`` - to get ride of changesets. + to get rid of changesets. * The **evolve** mercurial extension to rewrite history using *obsolete marker* under the hood. - The first and most important step is by far the **obsolete marker**. However -most user will never be directly exposed to the concept. For this reason -document about changeset evolution are put first. - +most users will never be directly exposed to the concept. For this reason +this manual starts with changeset evolution. Evolve: A robust alternative to MQ ==================================== -Evolve is an experimental history rewriting extensions that use obsolete -markers. It is inspired from MQ and pbranch but have multiple advantage over +Evolve is an experimental history rewriting extension that uses obsolete +markers. It is inspired from MQ and pbranch but have multiple advantages over them: * Focus on your current work. @@ -46,25 +45,25 @@ Simple conflict are handled by real merge tools using appropriate ancestor. Conflict are much rarer and much more user friendly. -* Mutable history are **fully available all the time**. +* Mutable history **fully available all the time**. - You are do not need to unapply and apply patche to access various part of you - history. + always use 'hg update' and forget about (un)applying patches to access the + mutable part of your history. + -* Use **plain changeset** only. +* Use only **plain changeset** and forget about patches. Evole will create and + exchange real changesets. Mutable history can be used in all usual operations: + pull, push, log, diff, etc. - Evolve create and exchange real changeset only, not patches. - Mutable history can be used in all usual operation 'pull, push, log, diff …) - -* Allow **sharing and collaboration** mutable history without fear of duplicate. +* Allow **sharing and collaboration** mutable history without fear of duplicate (thanks to obsolete marker). * Cover all mq usage but guard. .. warning:: The evolve extention and the obsolete marker are at an experimental - stage. While using obsolet you'll likely be exposed to complexe + stage. While using obsolete you'll likely be exposed to complex implication of the **obsolete marker** concept. I do not recommend - non power user to test this at this stage. + non-power user to test this at this stage. XXX make sure to read the XXX section before using it. @@ -108,15 +107,15 @@ - Very fast history rewriting operations, -- auditable and reversible history rewritting process, +- auditable and reversible history rewriting process, - clean final history, -- share and collaborate on mutable part of the history, +- share and collaborate on mutable parts of the history, -- gracefully handle history rewriting conflict, +- gracefully handle history rewriting conflicts, -- allows various history rewriting UI to collaborate with a underlying common API. +- allow various history rewriting UI to collaborate with a underlying common API. --- @@ -129,9 +128,14 @@ obs-implementation - +Known caveats +============= +Here is a list of known issues that will be fixed later: +* Unstable changeset turn secret. + +* ``hg stabilize`` does not handle conflicts. Known limitation and bug ================================= @@ -144,16 +148,16 @@ You must fallback to graft or rebase when that happen. -* rewritinf conflict are not detected yet``hg stabilize`` does not handle them. +* rewriting conflict are not detected yet``hg stabilize`` does not handle them. * ``hg update`` can move an obsolete parent * you need to provide to `graft --continue -O` if you started you graft using `-O`. -* hg merge considered extinct head as valid target. requiring you to manually - specify target all the time. +* ``hg merge`` considers an extinct head to be a valid target, hence requiring + you to manually specify target all the time. -* obsolete relation exchange crash (as in traceback) on static http repo. +* trying to exchange obsolete relations with a static http repo will crash. * Extinct changeset are turned secret by various commands. @@ -170,14 +174,18 @@ * hg graphlog show extinct changeset * Mercurial 2.1 think you are pushing additional heads even when the new head - obsolete another one. You have to use hg push -f more than necessary. - + obsolete another one. You have to use hg push -f more often than necessary. +* ``hg heads`` shows extinct changeset +* ``hg merge`` considers an extinct head to be a valid target, hence requiring + you to manually specify target all the time. + +* trying to exchange obsolete relations with a static http repo will crash. Annexe -================================= +====== .. toctree:: :maxdepth: 1
--- a/docs/obs-concept.rst Wed May 09 13:08:46 2012 +0200 +++ b/docs/obs-concept.rst Wed May 09 14:24:56 2012 +0200 @@ -76,8 +76,6 @@ replace that. In highly distributed environments, a user may end up with conflicting references and no proper way to choose. -XXX for the above paragraph link to "unstable issue" - Because of this way to visualize a repository, git-branches are a core part of git, which makes the user interface more complicated and constrains moving through history. @@ -93,7 +91,7 @@ As None of the concepts was powerful enough to fulfill the need of safely rewriting history, including easy sharing and collaborating on mutable history, -we needed another one. +we needed another one. Basic concept -----------------------------------------------------
--- a/docs/obs-implementation.rst Wed May 09 13:08:46 2012 +0200 +++ b/docs/obs-implementation.rst Wed May 09 14:24:56 2012 +0200 @@ -21,27 +21,13 @@ Abstraction from history rewriting UI ``````````````````````````````````````````` -How Mercurial handle obsolete marker is independent from what create -them and what actual operation solves error case. Any of the existing history +How Mercurial handle obsolete marker is independent from who decide to create +them and what actual operation solve error case. Any of the existing history rewriting UI (rebase, mq, histedit) can lay obsolete marker and resolve situation created by other. To go further a hook system of obsolete marker creation would allow each mechanism to collaborate with other though a standard and central mechanism. -Obsolete marker content -``````````````````````````` - -In the current implementation obsolete marker contains:: - - 'id': "unique id of the obsolete marker" - 'subjects': "0-N newer version of changeset in "object" (as ordered list) - 'object': "old and obsolete version" - 'date': "When was this marker created ?" - 'user': "Who did that ?" - 'reason': "Why was it done" - -Grouping them for operation that create multiple markers are once may be a good -idea. (would help, exchange and cancelation) Obsolete marker storage ``````````````````````````` @@ -90,18 +76,18 @@ An experimental implementatione exists. What have been done so far. -* rich markers stored outside history, -* obsolete markers exchange through pushkey, +* 1-1 obsolete marker stored outside history, -* compute obsolete-tip (newest version of a changeset) +* compute obsolete-tip + +* obsolete marker exchange through pushkey, * compute obsolete, unstable, extinct and suspended set. * hidden extinct changesets for UI. -* Require `--force` to push unstable history. - -* Use secret phase to remove extinct changesets from discovery. +* Use secret phase to remove from discovery obsolete and unstable changeset (to + be improved soon) * alter rebase to use obsolete marker instead of stripping. (XXX break --keep for now)
--- a/docs/tutorials/tutorial.t Wed May 09 13:08:46 2012 +0200 +++ b/docs/tutorials/tutorial.t Wed May 09 14:24:56 2012 +0200 @@ -1,24 +1,20 @@ -Mutable History and collaboration -===================================================================== - +=================================== + Mutable History and collaboration +=================================== .. warning:: need heavy update - Single Developer Usage ====================== This tutorial shows how to use evolution to replace the basics of *mq*. - Amending a changeset --------------------- - First there is some setup phase you will understand later. -there is a local repository and a remote one. - +There is a local repository and a remote one. $ cat >> $HGRCPATH << EOF > [ui]
--- a/docs/unstability.rst Wed May 09 13:08:46 2012 +0200 +++ b/docs/unstability.rst Wed May 09 14:24:56 2012 +0200 @@ -1,4 +1,3 @@ - ----------------------------------- The Unstability Principle ----------------------------------- @@ -8,7 +7,6 @@ An intrinsic contradiction ----------------------------------- -XXX starts by talking about getting ride of changeset. DVCS bring two new major concepts to the Version Control Scene: @@ -27,8 +25,6 @@ All three elements are used generate a *unique* hash that identify the changeset (with various other metadata). This identification is a key part of DVCS design. -XXX missing lines ? - :: Schema base, A, B and B' @@ -60,150 +56,73 @@ Everybody is working around the issue ------------------------------------------------ -I'm not claiming that rewriting history is impossible. People are successfully -doing for years. However they all need to work around this unstability: +I'm not claiming that rewriting history is impossible. People are Rewriting all at once `````````````````````````` -The simplest way to avoid unstability is to ensure rewritting operation always -ends in a stable situation. This is achieve by rewriting all impacted changeset -at the same time. - -rewritting all descendants at the same time that the rewritting of a changeset. - -:: - - Schema! - -Several Mercurial command follow this idea: rebase, collapse, histedit. -Mercurial also refuse to amend changeset with descendant. The git brnach design enforce such approach in git too. -However, DVCS are **Distributed**. This means that you do not control what -happen outside your repository. Once a changeset have been exchanged *outside*, -you can't be sure of it's descendant. Therefore** if you rewritte changeset that -exists elsewere, you can't erradicate the risk of unstability.** +stable situation to stable situation -Do not rewrite exchanged changeset -``````````````````````````````````` +Distributed means that you do not control what happen outside your repository: + -To work around this issue mercurial introduced phases that prevent you to -rewrite exchanged changeset and ensure other can't pull certain changeset from -you. But this is a very frustrating limitation that prevent you to -efficiently share, review and collaborate on mutable changeset. +* phase. +* overwrite. -Git world use another approach to prevent unstability. -By convention only a single developper works on a changeset contained in a named -branch. But once again this is a huge blocker for collaborating and clueless people -**will** mess up social convention soon or later. + +Boiler Plate Loose the DAG robustness ```````````````````````````` -The other approach use in Mercurial is to keep the mutable part of the history -outside the DVCS constraint. This is the MQ approach of sticking a quilt queue -over Mercurial. +The other approach is -This allow much more flexible workflow two major feature are lost in the -process: +mq -- quilt - * Graceful merge. MQ use plain-patch to store changeset content and patch have - trouble to apply in changing context. applying you queu can because very - painful if context changeset. +Conflict too much conflict - * easy branching. A quilt queue is by definition a linear queue. +Linear -It is possible to collaborate over versionned mq! But you are going ahead a lot -of trouble. -.. Ignore conflicts -.. ``````````````````````````````````` -.. -.. Another ignored issue is conflicting rewritting of the same changeset. If a -.. changeset is rewritten two times we have two newer version, duplicated history -.. complicate to merge. -.. -.. Mercurial work around by -.. -.. The "One set of mutable changset == One developper" mantra is also a way to work -.. around conflicting rewritting of changeset. If two different people are able to -.. -.. The git branch model allow to overwrite changeset version by another one. But it -.. does not care about divergent version. It is the equilent of "common ftp" source -.. management for changeset. +Deny a lot of option +```````````````````````````` + + + +[] rewrite + +[] exchange + +[] collaborate + Facing The Danger Once And For All ------------------------------------------------ The more effort you put to avoid instability, the more option you deny. And even most restrictive work flow can't garantee that instability will never show up! -Obsolete marker can handle the job -``````````````````````````````````` - It is time to provide a full featured solution to deal with instability and to stop working around the issue! This is why I developing a new feature for -mercurial called "Obsolete marker". Obsolete marker have two key property: +mercurial called "Obsolete marker". * Any changeset is we want to get ride of is **explicitly** marked as "obsolete" - by history rewritting operation. - - By explicitly marking the obsolete part of the history, we will be able to - easily detect appearance of unstability. + by history rewritting operation.. * Relations between old and new version of changesets are tracked by Obsolete markers. - By Storing a meta-history of changeset evolution we are able to easily resolve - instability and edition conflict [#]_ . - -.. [#] edition conflict is another major obstable to collaboration. See the - section dedicated to obsolete marker for details. - -Improving robusness improves simplicity -```````````````````````````````````````````````` - -This proposal should **first** be seen as a safety measure. - -It allow to detect unstability as soon as possible - -:: - $ hg pull - added 3 changeset - +2 unstable changeset - (do you want "hg stabilize" ?) - working directory parent is obsolete! - $ hg push - outgoing unstable changesets - (use "hg stabilize" or force the push) - -And should not not encourage people to create unstability - -:: - $ hg up 42 - $ hg commit --amend - changeset have descendant. - $ hg commit --amend -f - +5 unstable changeset - - $ hg rebase -D --rev 40::44 - rebasing already obsolete changeset 42:AAA will conflict with newer version 48:BBB - -While allowing powerful feature -```````````````````````````````````````````````` - -* "kill" changeset remotely. - -* track resulting changeset when submitting patch//pull request. - -* Focus on what you do: - - I do not like the "all at once" model of history rewriting. I'm confortable - with unstability and obsolete marker offer all the tool to safely create and - handle unstability locally. +By explicitly marking the obsolete part of the history, we will be able to +easily detect appearance of unstability. By Storing a meta-history of changeset +evolution we are able to easily resolve instability and edition conflict. + + +No instability is still a bad situation. +No instability is still a bad situation that should be avoided.
--- a/hgext/evolve.py Wed May 09 13:08:46 2012 +0200 +++ b/hgext/evolve.py Wed May 09 14:24:56 2012 +0200 @@ -7,7 +7,7 @@ # This software may be used and distributed according to the terms of the # GNU General Public License version 2 or any later version. -'''A set of command to make changeset evolve.''' +'''a set of commands to handle changeset mutation''' from mercurial import cmdutil from mercurial import scmutil @@ -187,7 +187,7 @@ ], '') def stabilize(ui, repo, **opts): - """move changeset out of they unstable state + """move changeset out of the unstable state By default only works on changeset that will be rebase on ancestors of the current working directory parent (included)""" @@ -250,8 +250,9 @@ @command('^gdown', [], - 'update to working directory parent an display summary lines') + '') def cmdgdown(ui, repo): + """update to working directory parent an display summary lines""" wkctx = repo[None] wparents = wkctx.parents() if len(wparents) != 1: @@ -272,8 +273,9 @@ @command('^gup', [], - 'update to working directory children an display summary lines') + '') def cmdup(ui, repo): + """update to working directory children an display summary lines""" wkctx = repo[None] wparents = wkctx.parents() if len(wparents) != 1:
--- a/hgext/obsolete.py Wed May 09 13:08:46 2012 +0200 +++ b/hgext/obsolete.py Wed May 09 14:24:56 2012 +0200 @@ -19,61 +19,59 @@ changeset history. Standard changeset history versions files. The *obsolete* relation versions changesets. -:obsolete: a changeset that have been replace by another one. -:unstable: a non-obsolet changeset based on another one. +:obsolete: a changeset that has been replaced by another one. +:unstable: a changeset that is not obsolete but has an obsolete ancestor. :suspended: an obsolete changeset with unstable descendant. -:extinct: an obsolete changeset without unstable descendant +:extinct: an obsolete changeset without unstable descendant. (subject to garbage collection) Another name for unstable could be out of sync. - Usage and Feature ================= - Display and Exchange -.................... +-------------------- obsolete changesets are hidden. (except if they have non obsolete changeset) -obsolete changesets are currently not exchange. This will probably change later -but it was the simpler solution for now. +obsolete changesets are not exchanged. This will probably change later but it +was the simpler solution for now. New commands -............ +------------ -a ``debugobsolete`` command has been added. - -It add an obsolete relation between too relation. +A ``debugobsolete`` command was added. It adds an obsolete relation between two +nodes. Context object -.............. +-------------- -Context gain a ``obsolete`` method that return True if a changeset is obsolete -False otherwise. +Context gains a ``obsolete`` method that will return True if a changeset is +obsolete False otherwise. revset -...... +------ Add an ``obsolete()`` entry. repo extension -.............. +-------------- To Do ------ +~~~~~ -* refuse to obsolete published changesets +- refuse to obsolete published changesets -* handle split +- handle split -* handle conflict +- handle conflict -* handle unstable // out of sync +- handle unstable // out of sync """ + import os try: from cStringIO import StringIO @@ -815,7 +813,7 @@ journalpath = self.sjoin(journalname) util.copyfile(filepath, journalpath) - else: # XXX remove this bloc while breaking support to Hg 2.1 + else: # XXX removing this bloc will break Hg 2.1 support def _writejournal(self, desc): """wrapped version of _writejournal that save obsolete data""" entries = list(o_writejournal(desc)) @@ -845,7 +843,7 @@ @storecache('00changelog.i') def changelog(self): - # << copy pasted from mercurila source + # << copy pasted from mercurial source c = changelog.changelog(self.sopener) if 'HG_PENDING' in os.environ: p = os.environ['HG_PENDING'] @@ -882,5 +880,3 @@ phases.retractboundary(repo, 2, expobs) finally: lock.release() - -