Patchwork [1,of,2] remotenames: record bookmark changes in the journal

login
register
mail settings
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 - July 1, 2016, 11:57 a.m.
# 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.
Sean Farley - July 1, 2016, 5:08 p.m.
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?
Martijn Pieters - July 1, 2016, 5:27 p.m.
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
Sean Farley - July 1, 2016, 5:55 p.m.
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.
Martijn Pieters - July 4, 2016, 10:52 a.m.
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.
Martijn Pieters - July 4, 2016, 3:26 p.m.
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. :-)
Sean Farley - July 14, 2016, 1:33 a.m.
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 - July 22, 2016, 7:50 p.m.
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
+