| Submitter | Martijn Pieters |
|---|---|
| Date | July 1, 2016, 11:57 a.m. |
| Message ID | <765689026f562a92b8eb.1467374267@mjpieters-mbp.dhcp.thefacebook.com> |
| Download | mbox | patch |
| Permalink | /patch/15698/ |
| State | Accepted |
| Delegated to: | Sean Farley |
| Headers | show |
Comments
Martijn Pieters <mj@zopatista.com> writes: > # HG changeset patch > # User Martijn Pieters <mjpieters@fb.com> > # Date 1467374115 -3600 > # Fri Jul 01 12:55:15 2016 +0100 > # Node ID 765689026f562a92b8eb58f4b4fad28cbbd4009b > # Parent 183d5b47f7472b839a96e7be735bb7fbf8068969 > remotenames: record bookmark changes in the journal > > Any changed remote names are logged in the journal so users can track where the > bookmark pointed to before. Why not store everything in the journal? Can't we just query it for all remotenames and use that information to label / namespace things?
On 1 Jul 2016, at 18:08, Sean Farley <sean@farley.io> wrote: >> Any changed remote names are logged in the journal so users can track where the >> bookmark pointed to before. > > Why not store everything in the journal? Can't we just query it for all > remotenames and use that information to label / namespace things? Because the journal tracks *changes* in bookmarks. If you have journal enabled, when you first clone the repo, you'll have all remote names recorded automatically anyway. Martijn
Martijn Pieters <mj@zopatista.com> writes: > [ Unknown signature status ] > On 1 Jul 2016, at 18:08, Sean Farley <sean@farley.io> wrote: >>> Any changed remote names are logged in the journal so users can track where the >>> bookmark pointed to before. >> >> Why not store everything in the journal? Can't we just query it for all >> remotenames and use that information to label / namespace things? > > Because the journal tracks *changes* in bookmarks. If you have journal enabled, when you first clone the repo, you'll have all remote names recorded automatically anyway. I understand that. What I'm trying to say is that there are too many data stores right now and that I don't want another one. I don't think it'd be too hard to abstract things such that there is a journaled interaface to namespaces.
On 1 July 2016 at 18:55, Sean Farley <sean@farley.io> wrote: > Martijn Pieters <mj@zopatista.com> writes: > >> [ Unknown signature status ] >> On 1 Jul 2016, at 18:08, Sean Farley <sean@farley.io> wrote: >>>> Any changed remote names are logged in the journal so users can track where the >>>> bookmark pointed to before. >>> >>> Why not store everything in the journal? Can't we just query it for all >>> remotenames and use that information to label / namespace things? >> >> Because the journal tracks *changes* in bookmarks. If you have journal enabled, when you first clone the repo, you'll have all remote names recorded automatically anyway. > > I understand that. What I'm trying to say is that there are too many > data stores right now and that I don't want another one. I don't think > it'd be too hard to abstract things such that there is a journaled > interaface to namespaces. Ah, I got confused and picked the wrong definition for 'namespaces' here. I'll take a look if that's a possibility, I'm not that familiar with how namespaces are recorded. However, this would require that we record the current command and username each and every time if we want to be able to show that when listing journal entries.
On 1 July 2016 at 18:08, Sean Farley <sean@farley.io> wrote: > Martijn Pieters <mj@zopatista.com> writes: > >> # HG changeset patch >> # User Martijn Pieters <mjpieters@fb.com> >> # Date 1467374115 -3600 >> # Fri Jul 01 12:55:15 2016 +0100 >> # Node ID 765689026f562a92b8eb58f4b4fad28cbbd4009b >> # Parent 183d5b47f7472b839a96e7be735bb7fbf8068969 >> remotenames: record bookmark changes in the journal >> >> Any changed remote names are logged in the journal so users can track where the >> bookmark pointed to before. > > Why not store everything in the journal? Can't we just query it for all > remotenames and use that information to label / namespace things? Now that I have the right context, a second attempt at answering this. :-) I don't think an experimental extension is the place to replace the storage for all 3 of the current core namespaces: bookmarks, tags and branches. I see where this is going, and if the information that journal provides should be part of the core at some point, then yes, I agree that storing the information (who changed what name when) as part of the bookmark / tag / branch storage and exposing that via the namespace API is a great idea. But it is outside the scope and ambition for this extension for now. :-)
Martijn Pieters <mj@zopatista.com> writes: > On 1 July 2016 at 18:08, Sean Farley <sean@farley.io> wrote: >> Martijn Pieters <mj@zopatista.com> writes: >> >>> # HG changeset patch >>> # User Martijn Pieters <mjpieters@fb.com> >>> # Date 1467374115 -3600 >>> # Fri Jul 01 12:55:15 2016 +0100 >>> # Node ID 765689026f562a92b8eb58f4b4fad28cbbd4009b >>> # Parent 183d5b47f7472b839a96e7be735bb7fbf8068969 >>> remotenames: record bookmark changes in the journal >>> >>> Any changed remote names are logged in the journal so users can track where the >>> bookmark pointed to before. >> >> Why not store everything in the journal? Can't we just query it for all >> remotenames and use that information to label / namespace things? > > Now that I have the right context, a second attempt at answering this. :-) > > I don't think an experimental extension is the place to replace the > storage for all 3 of the current core namespaces: bookmarks, tags and > branches. I see where this is going, and if the information that > journal provides should be part of the core at some point, then yes, I > agree that storing the information (who changed what name when) as > part of the bookmark / tag / branch storage and exposing that via the > namespace API is a great idea. But it is outside the scope and > ambition for this extension for now. :-) Ok, this is a good argument and I agree with your points. I've queued this for testing (hopefully will use it tomorrow!)
Sean Farley <sean@farley.io> writes: > Martijn Pieters <mj@zopatista.com> writes: > >> On 1 July 2016 at 18:08, Sean Farley <sean@farley.io> wrote: >>> Martijn Pieters <mj@zopatista.com> writes: >>> >>>> # HG changeset patch >>>> # User Martijn Pieters <mjpieters@fb.com> >>>> # Date 1467374115 -3600 >>>> # Fri Jul 01 12:55:15 2016 +0100 >>>> # Node ID 765689026f562a92b8eb58f4b4fad28cbbd4009b >>>> # Parent 183d5b47f7472b839a96e7be735bb7fbf8068969 >>>> remotenames: record bookmark changes in the journal >>>> >>>> Any changed remote names are logged in the journal so users can track where the >>>> bookmark pointed to before. >>> >>> Why not store everything in the journal? Can't we just query it for all >>> remotenames and use that information to label / namespace things? >> >> Now that I have the right context, a second attempt at answering this. :-) >> >> I don't think an experimental extension is the place to replace the >> storage for all 3 of the current core namespaces: bookmarks, tags and >> branches. I see where this is going, and if the information that >> journal provides should be part of the core at some point, then yes, I >> agree that storing the information (who changed what name when) as >> part of the bookmark / tag / branch storage and exposing that via the >> namespace API is a great idea. But it is outside the scope and >> ambition for this extension for now. :-) > > Ok, this is a good argument and I agree with your points. I've queued > this for testing (hopefully will use it tomorrow!) A bit behind scheduled but I was finally able to test this and pushed it. It's really great!
Patch
diff --git a/remotenames.py b/remotenames.py --- a/remotenames.py +++ b/remotenames.py @@ -39,10 +39,13 @@ from mercurial import url from mercurial import util from mercurial.i18n import _ -from mercurial.node import hex, short, bin +from mercurial.node import hex, short, bin, nullid from hgext import schemes from hgext.convert import hg as converthg +# namespace to use when recording an hg journal entry +journalremotebookmarktype = 'remotebookmark' + def exbookcalcupdate(orig, ui, repo, checkout): '''Return a tuple (targetrev, movemarkfrom) indicating the rev to check out and where to move the active bookmark from, if needed.''' @@ -1327,6 +1330,16 @@ elif nametype == 'bookmarks': oldbooks[rname] = node + # record a journal entry if journal is loaded + if util.safehasattr(repo, 'journal'): + for rmbookmark, newnode in bookmarks.iteritems(): + oldnode = oldbooks.get(rmbookmark, hex(nullid)) + if oldnode != newnode: + joinedremotename = joinremotename(remotepath, rmbookmark) + repo.journal.record( + journalremotebookmarktype, joinedremotename, + bin(oldnode), bin(newnode)) + for branch, nodes in branches.iteritems(): for n in nodes: rname = joinremotename(remotepath, branch) diff --git a/tests/test-journal.t b/tests/test-journal.t new file mode 100644 --- /dev/null +++ b/tests/test-journal.t @@ -0,0 +1,64 @@ +Tests for the journal extension integration with remotenames. + +Skip if journal is not available in mercurial + + $ if ! hg help -e journal &>/dev/null; then + > echo 'skipped: missing feature: journal' + > exit 80 + > fi + + $ cat >> $HGRCPATH << EOF + > [extensions] + > journal= + > remotenames=`dirname $TESTDIR`/remotenames.py + > [remotenames] + > rename.default=remote + > EOF + + $ hg init remote + $ cd remote + $ touch a + $ hg commit -A -m 'a commit' -q + $ hg book bmwillnotmove + $ hg book bm + +Test journal with remote bookmarks works on clone + + $ cd .. + $ hg clone remote local -q + $ cd local + $ hg journal remote/bm + previous locations of 'remote/bm': + 94cf1ae9e2c8 clone remote local -q + +Test journal with remote bookmarks works on pull + + $ cd ../remote + $ hg up bm -q + $ echo 'modified' > a + $ hg commit -m 'a second commit' -q + $ cd ../local + $ hg pull -q + $ hg journal remote/bm + previous locations of 'remote/bm': + b720e98e7160 pull -q + 94cf1ae9e2c8 clone remote local -q + +Test journal with remote bookmarks works after push + + $ hg up remote/bm -q + $ echo 'modified locally' > a + $ hg commit -m 'local commit' -q + $ hg push --to bm -q + $ hg journal remote/bm + previous locations of 'remote/bm': + 869ef7e9b417 push --to bm -q + b720e98e7160 pull -q + 94cf1ae9e2c8 clone remote local -q + +Test second remotebookmark has not been clobbered or has moved since clone + + $ hg journal remote/bmwillnotmove + previous locations of 'remote/bmwillnotmove': + 94cf1ae9e2c8 clone remote local -q +