Patchwork convert: add --authormapsuffix to append set text to author names (issue4171)

login
register
mail settings
Submitter lstewart@room52.net
Date Feb. 14, 2014, 12:30 a.m.
Message ID <2b6fdac02ea3ae0fdefa.1392337850@lgwl-lstewart2.corp.netflix.com>
Download mbox | patch
Permalink /patch/3655/
State Rejected
Headers show

Comments

lstewart@room52.net - Feb. 14, 2014, 12:30 a.m.
# HG changeset patch
# User lstewart
# Date 1392337372 -39600
#      Fri Feb 14 11:22:52 2014 +1100
# Node ID 2b6fdac02ea3ae0fdefa8d0738f7df679a80dcfd
# Parent  80628d4069be724089ea487a300d62f4cbd8970d
convert: add --authormapsuffix to append set text to author names (issue4171)

The --authormap option to convert does not provide a mechanism to template how
author names should be mapped from the source to destination repository. In the
absence of a more complete templating like feature, this new option allows some
set text to be appended to every author name during the conversion. This is
particularly useful for changing project-local usernames into globally
distinguishable author identifiers e.g. by mapping "lstewart" ->
"lstewart@FreeBSD.org", without first having to obtain a list of all authors in
the source repository and create an authormap from that list.

If --authormapsuffix is used concurrently with --authormap, the suffix is
appended to post-authormap-translated names as well as non-authormap-translated
names.
Mads Kiilerich - Feb. 14, 2014, 1:52 a.m.
On 02/14/2014 01:30 AM, lstewart@room52.net wrote:
> # HG changeset patch
> # User lstewart

(Yeah - you don't use the username configuration convention most 
Mercurial users use and that Mercurial and the documentation more or 
less recommends. That proves that the use case is somewhat valid.)

> # Date 1392337372 -39600
> #      Fri Feb 14 11:22:52 2014 +1100
> # Node ID 2b6fdac02ea3ae0fdefa8d0738f7df679a80dcfd
> # Parent  80628d4069be724089ea487a300d62f4cbd8970d
> convert: add --authormapsuffix to append set text to author names (issue4171)
>
> The --authormap option to convert does not provide a mechanism to template how
> author names should be mapped from the source to destination repository. In the
> absence of a more complete templating like feature, this new option allows some
> set text to be appended to every author name during the conversion. This is
> particularly useful for changing project-local usernames into globally
> distinguishable author identifiers e.g. by mapping "lstewart" ->
> "lstewart@FreeBSD.org", without first having to obtain a list of all authors in
> the source repository and create an authormap from that list.
>
> If --authormapsuffix is used concurrently with --authormap, the suffix is
> appended to post-authormap-translated names as well as non-authormap-translated
> names.

You mention the lack of a more complete templating like feature. How 
could it look like? Could we aim at that instead?

Convert has a big pile of hacks. I can be blamed for some of them. All 
of the hacks made sense and solved a real problem ... but together they 
have made convert far from "elegant". Tagmap is the latest example. I 
don't think adding more options and features necessarily makes convert 
better or more useful.

By now it has been proven that there are valid use cases for changing 
almost anything while converting. But should we continue to add an 
infinite number of options, one by one? It seems like what we are 
missing is:
* a framework (or documentation?) for easy mangling of changesets with 
Python snippets while converting
* as one example of that, a more generic configurable framework that can 
apply 'mapfiles' or regexps too all kind of changeset properties

Some inspiration could come from existing functionality such as 
authormap and branchmap and tagmap, the hg transplant --filter option, 
hooks, subpaths ... and postfix lookup tables and???

This use case could perhaps be solved with configuration like

convert.ini:
[author]
# default is regexp like subpaths
(.*)$ = \1@FreeBSD.org
# "mapfile" is reserved and can be used to implement --authormap:
# mapfile = FILE

used as
hg convert --filter=convert.ini ...

or

mangle.py:
class mysource(hgext.convert.hg.mercurial_source):
     def getcommit(rev):
         c = hgext.convert.hg.mercurial_source.getcommit(rev)
         c.author = c.author + '@FreeBSD.org'
         return c

used as
hg convert --source-type=mangle.py:mysource ...

- or something like that. The syntax examples are just quickly made up, 
but it seems like they also could solve other valid use cases ... such 
as tagmap.

Back to authormapsuffix:

In this specific case it wouldn't be hard to make a first run to get a 
list of authors, generate a authormap with a bit of scripting, and just 
use that.

Other equally valid kinds of author rewriting would still either require 
their own option ... or could be solved with the same generic method. 
The needs that could come next could be domain renaming or 
adding/removing full names ... or exceptions for those who already 
configured with domain.

I am thus a bit reluctant to recommend this patch. Technically it is 
fine, but from a product management perspective it adds compatibility 
constraints and doesn't move us in an obviously right direction.

/Mads
lstewart@room52.net - Feb. 14, 2014, 3:57 a.m.
Hi Mads,

On 02/14/14 12:52, Mads Kiilerich wrote:
> On 02/14/2014 01:30 AM, lstewart@room52.net wrote:
>> # HG changeset patch
>> # User lstewart
> 
> (Yeah - you don't use the username configuration convention most
> Mercurial users use and that Mercurial and the documentation more or
> less recommends. That proves that the use case is somewhat valid.)

;)

I have a bunch of projects I use Mercurial for and often configure my
username pref in the repository's hgrc file rather than my ~/.hgrc such
that it only applies to that project. I obviously forgot to do it for my
checkout of the official Mercurial repo which I've been hacking in.

>> # Date 1392337372 -39600
>> #      Fri Feb 14 11:22:52 2014 +1100
>> # Node ID 2b6fdac02ea3ae0fdefa8d0738f7df679a80dcfd
>> # Parent  80628d4069be724089ea487a300d62f4cbd8970d
>> convert: add --authormapsuffix to append set text to author names
>> (issue4171)
>>
>> The --authormap option to convert does not provide a mechanism to
>> template how
>> author names should be mapped from the source to destination
>> repository. In the
>> absence of a more complete templating like feature, this new option
>> allows some
>> set text to be appended to every author name during the conversion.
>> This is
>> particularly useful for changing project-local usernames into globally
>> distinguishable author identifiers e.g. by mapping "lstewart" ->
>> "lstewart@FreeBSD.org", without first having to obtain a list of all
>> authors in
>> the source repository and create an authormap from that list.
>>
>> If --authormapsuffix is used concurrently with --authormap, the suffix is
>> appended to post-authormap-translated names as well as
>> non-authormap-translated
>> names.
> 
> You mention the lack of a more complete templating like feature. How
> could it look like? Could we aim at that instead?

We certainly could and probably should. Only reason I proposed this
patch is that it exists now, works as advertised and I've been using it
during my setup of http://hg-beta.freebsd.org/ (currently offline for
another few hours while I rerun the conversion with my --authormapsuffix
patch so that authors are mapped to @FreeBSD.org so that downstream
consumers of the repo can better differentiate from changes made by
upstream authors vs local authors).

> Convert has a big pile of hacks. I can be blamed for some of them. All
> of the hacks made sense and solved a real problem ... but together they
> have made convert far from "elegant". Tagmap is the latest example. I
> don't think adding more options and features necessarily makes convert
> better or more useful.
> 
> By now it has been proven that there are valid use cases for changing
> almost anything while converting. But should we continue to add an
> infinite number of options, one by one? It seems like what we are
> missing is:
> * a framework (or documentation?) for easy mangling of changesets with
> Python snippets while converting
> * as one example of that, a more generic configurable framework that can
> apply 'mapfiles' or regexps too all kind of changeset properties

Indeed, that sounds like a good path forward and pretty much the sort of
thing I had in mind when I referred to a templating system in the bug
description.

> Some inspiration could come from existing functionality such as
> authormap and branchmap and tagmap, the hg transplant --filter option,
> hooks, subpaths ... and postfix lookup tables and???
> 
> This use case could perhaps be solved with configuration like
> 
> convert.ini:
> [author]
> # default is regexp like subpaths
> (.*)$ = \1@FreeBSD.org
> # "mapfile" is reserved and can be used to implement --authormap:
> # mapfile = FILE
> 
> used as
> hg convert --filter=convert.ini ...
> 
> or
> 
> mangle.py:
> class mysource(hgext.convert.hg.mercurial_source):
>     def getcommit(rev):
>         c = hgext.convert.hg.mercurial_source.getcommit(rev)
>         c.author = c.author + '@FreeBSD.org'
>         return c
> 
> used as
> hg convert --source-type=mangle.py:mysource ...
> 
> - or something like that. The syntax examples are just quickly made up,
> but it seems like they also could solve other valid use cases ... such
> as tagmap.

As an off-the-cuff first stab at things, the above seems like a good
starting point to me and on the right track.

> Back to authormapsuffix:
> 
> In this specific case it wouldn't be hard to make a first run to get a
> list of authors, generate a authormap with a bit of scripting, and just
> use that.

So the problem with that (and the reason I hacked up this patch) is I'm
running a continual conversion against the FreeBSD svn source every 15
mins, and the only way to make the above robust is to regenerate the
authormap before every sync. Otherwise, when new committers join the
project they won't be in the authormap and would fail to get mapped to
<username>@FreeBSD.org

The --authormapsuffix appends to any authorname encountered so I never
run the risk of an unsuffixed authorname making it into the Hg repo.

> Other equally valid kinds of author rewriting would still either require
> their own option ... or could be solved with the same generic method.
> The needs that could come next could be domain renaming or
> adding/removing full names ... or exceptions for those who already
> configured with domain.

Yes.

> I am thus a bit reluctant to recommend this patch. Technically it is
> fine, but from a product management perspective it adds compatibility
> constraints and doesn't move us in an obviously right direction.

I would be happy to be engaged with the templating system project we're
discussing, but don't have sufficient cycles to take it on by myself or
to be the primary driver of the project.

As for the patch at hand, I'm willing to accept dev crew consensus on
whether putting it in now is worthwhile or not. My general feeling is a
bird in the hand that works and addresses a straight forward use case is
worth having with an understanding there is a longer term goal to move
to the flexible templating system.

Cheers,
Lawrence
lstewart@room52.net - Feb. 15, 2014, 12:50 a.m.
On 02/14/14 14:57, Lawrence Stewart wrote:
> Hi Mads,
> 
> On 02/14/14 12:52, Mads Kiilerich wrote:
[snip]
>>
>> You mention the lack of a more complete templating like feature. How
>> could it look like? Could we aim at that instead?
> 
> We certainly could and probably should. Only reason I proposed this
> patch is that it exists now, works as advertised and I've been using it
> during my setup of http://hg-beta.freebsd.org/ (currently offline for
> another few hours while I rerun the conversion with my --authormapsuffix
> patch so that authors are mapped to @FreeBSD.org so that downstream
> consumers of the repo can better differentiate from changes made by
> upstream authors vs local authors).

FYI, http://hg-beta.freebsd.org/ is back up if anyone is interested to
take a look. It is being instantiated as a read-only seed repository to
facilitate non-blessed committers and organisations developing
FreeBSD-derived products to be able to more easily track and hack
FreeBSD. I am putting together corresponding documentation to explain
how to do useful things with it, which might be interesting to get some
Mercurial community feedback on at some stage.

The FreeBSD svn source repo represents something of an interesting
conversion challenge, with the partially converted repo (trunk and
stable branches only currently, more branches will likely follow later)
coming in at ~240k commits, ~1GB size on disk.

As an aside, being able to detect MFCes (cherry-pick merges from the
head/trunk branch back to stable branches) and add appropriate ancestral
links during the conversion would be a nice outcome of a more advanced
snippets/templating based arrangement. As far as I know, it's currently
impossible to achieve this on-the-fly when doing incremental conversion
runs against the svn source of truth.

Cheers,
Lawrence
Augie Fackler - Feb. 18, 2014, 8:46 p.m.
On Sat, Feb 15, 2014 at 11:50:03AM +1100, Lawrence Stewart wrote:
> On 02/14/14 14:57, Lawrence Stewart wrote:
> > Hi Mads,
> >
> > On 02/14/14 12:52, Mads Kiilerich wrote:
> [snip]
> >>
> >> You mention the lack of a more complete templating like feature. How
> >> could it look like? Could we aim at that instead?
> >
> > We certainly could and probably should. Only reason I proposed this
> > patch is that it exists now, works as advertised and I've been using it
> > during my setup of http://hg-beta.freebsd.org/ (currently offline for
> > another few hours while I rerun the conversion with my --authormapsuffix
> > patch so that authors are mapped to @FreeBSD.org so that downstream
> > consumers of the repo can better differentiate from changes made by
> > upstream authors vs local authors).
>
> FYI, http://hg-beta.freebsd.org/ is back up if anyone is interested to
> take a look. It is being instantiated as a read-only seed repository to
> facilitate non-blessed committers and organisations developing
> FreeBSD-derived products to be able to more easily track and hack
> FreeBSD. I am putting together corresponding documentation to explain
> how to do useful things with it, which might be interesting to get some
> Mercurial community feedback on at some stage.
>
> The FreeBSD svn source repo represents something of an interesting
> conversion challenge, with the partially converted repo (trunk and
> stable branches only currently, more branches will likely follow later)
> coming in at ~240k commits, ~1GB size on disk.

Have you looked at hgsubversion at all? The facebook guys have done a
lot of work that might make this more straightforward.

>
> As an aside, being able to detect MFCes (cherry-pick merges from the
> head/trunk branch back to stable branches) and add appropriate ancestral
> links during the conversion would be a nice outcome of a more advanced
> snippets/templating based arrangement. As far as I know, it's currently
> impossible to achieve this on-the-fly when doing incremental conversion
> runs against the svn source of truth.

Does svn:mergeinfo get recorded on these merges? If so, it might be possible.

>
> Cheers,
> Lawrence
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Sean Farley - Feb. 18, 2014, 9:58 p.m.
Augie Fackler <raf@durin42.com> writes:

> On Sat, Feb 15, 2014 at 11:50:03AM +1100, Lawrence Stewart wrote:
>> On 02/14/14 14:57, Lawrence Stewart wrote:
>> > Hi Mads,
>> >
>> > On 02/14/14 12:52, Mads Kiilerich wrote:
>> [snip]
>> >>
>> >> You mention the lack of a more complete templating like feature. How
>> >> could it look like? Could we aim at that instead?
>> >
>> > We certainly could and probably should. Only reason I proposed this
>> > patch is that it exists now, works as advertised and I've been using it
>> > during my setup of http://hg-beta.freebsd.org/ (currently offline for
>> > another few hours while I rerun the conversion with my --authormapsuffix
>> > patch so that authors are mapped to @FreeBSD.org so that downstream
>> > consumers of the repo can better differentiate from changes made by
>> > upstream authors vs local authors).
>>
>> FYI, http://hg-beta.freebsd.org/ is back up if anyone is interested to
>> take a look. It is being instantiated as a read-only seed repository to
>> facilitate non-blessed committers and organisations developing
>> FreeBSD-derived products to be able to more easily track and hack
>> FreeBSD. I am putting together corresponding documentation to explain
>> how to do useful things with it, which might be interesting to get some
>> Mercurial community feedback on at some stage.
>>
>> The FreeBSD svn source repo represents something of an interesting
>> conversion challenge, with the partially converted repo (trunk and
>> stable branches only currently, more branches will likely follow later)
>> coming in at ~240k commits, ~1GB size on disk.
>
> Have you looked at hgsubversion at all? The facebook guys have done a
> lot of work that might make this more straightforward.
>
>>
>> As an aside, being able to detect MFCes (cherry-pick merges from the
>> head/trunk branch back to stable branches) and add appropriate ancestral
>> links during the conversion would be a nice outcome of a more advanced
>> snippets/templating based arrangement. As far as I know, it's currently
>> impossible to achieve this on-the-fly when doing incremental conversion
>> runs against the svn source of truth.
>
> Does svn:mergeinfo get recorded on these merges? If so, it might be possible.

It does and it's how I implemented the experimental merge history with
hgsubversion that I'm in the process of patch bombing :-)

Though, if someone could tell me how to distinguish between a
cherry-pick and merge, that would be great.
Pierre-Yves David - April 14, 2014, 4:45 a.m.
So, what about the original patch? Shall it be dropped or should we 
expect a new fixed version?
Mads Kiilerich - April 14, 2014, 6:30 p.m.
On 04/14/2014 06:45 AM, Pierre-Yves David wrote:
> So, what about the original patch? Shall it be dropped or should we 
> expect a new fixed version?
>

As mentioned Feb 14th, I think it would be better if it we could rework 
this into a more generic solution instead of releasing it and getting 
the liability of maintaining it forever.

On a very related note: the same applies to the fine patches that 
introduced closemap and tagmap - features that haven't been released yet.

I do however not have any code to show for a generic solution ...

/Mads
Pierre-Yves David - April 14, 2014, 6:34 p.m.
On 04/14/2014 02:30 PM, Mads Kiilerich wrote:
> On 04/14/2014 06:45 AM, Pierre-Yves David wrote:
>> So, what about the original patch? Shall it be dropped or should we
>> expect a new fixed version?
>>
>
> As mentioned Feb 14th, I think it would be better if it we could rework
> this into a more generic solution instead of releasing it and getting
> the liability of maintaining it forever.
>
> On a very related note: the same applies to the fine patches that
> introduced closemap and tagmap - features that haven't been released yet.
>
> I do however not have any code to show for a generic solution ...

I believe you have sensible concerns here. If I where you I would send a 
backout series to start the discussion.
Sean Farley - April 14, 2014, 6:36 p.m.
Mads Kiilerich <mads@kiilerich.com> writes:

> On 04/14/2014 06:45 AM, Pierre-Yves David wrote:
>> So, what about the original patch? Shall it be dropped or should we 
>> expect a new fixed version?
>>
>
> As mentioned Feb 14th, I think it would be better if it we could rework 
> this into a more generic solution instead of releasing it and getting 
> the liability of maintaining it forever.
>
> On a very related note: the same applies to the fine patches that 
> introduced closemap and tagmap - features that haven't been released yet.
>
> I do however not have any code to show for a generic solution ...

I completely agree. I just haven't had the time to write a way to plug
in custom python code :-(
lstewart@room52.net - April 15, 2014, 6:51 a.m.
On 04/15/14 04:36, Sean Farley wrote:
> 
> Mads Kiilerich <mads@kiilerich.com> writes:
> 
>> On 04/14/2014 06:45 AM, Pierre-Yves David wrote:
>>> So, what about the original patch? Shall it be dropped or should we 
>>> expect a new fixed version?
>>>
>>
>> As mentioned Feb 14th, I think it would be better if it we could rework 
>> this into a more generic solution instead of releasing it and getting 
>> the liability of maintaining it forever.
>>
>> On a very related note: the same applies to the fine patches that 
>> introduced closemap and tagmap - features that haven't been released yet.
>>
>> I do however not have any code to show for a generic solution ...
> 
> I completely agree. I just haven't had the time to write a way to plug
> in custom python code :-(

FWIW, I'm actively using the authormap patch for the hg-beta.freebsd.org
repo. I'm ok with dropping the patch for consideration and I can keep it
applied locally, but it would be good to have a plan for getting to the
generic solution we discussed a while back.

Cheers,
Lawrence

Patch

diff -r 80628d4069be -r 2b6fdac02ea3 hgext/convert/__init__.py
--- a/hgext/convert/__init__.py	Fri Jan 31 01:12:35 2014 -0800
+++ b/hgext/convert/__init__.py	Fri Feb 14 11:22:52 2014 +1100
@@ -85,6 +85,9 @@ 
 
     Empty lines and lines starting with a ``#`` are ignored.
 
+    The authormapsuffix can be used to append set text to each
+    post-authormap-translated author name.
+
     The filemap is a file that allows filtering and remapping of files
     and directories. Each line can contain one of the following
     directives::
@@ -321,6 +324,8 @@ 
            _('import up to source revision REV'), _('REV')),
           ('A', 'authormap', '',
            _('remap usernames using this file'), _('FILE')),
+          ('', 'authormapsuffix', '',
+           _('append this suffix to remapped author names'), _('SUFFIX')),
           ('', 'filemap', '',
            _('remap file names using contents of file'), _('FILE')),
           ('', 'splicemap', '',
diff -r 80628d4069be -r 2b6fdac02ea3 hgext/convert/convcmd.py
--- a/hgext/convert/convcmd.py	Fri Jan 31 01:12:35 2014 -0800
+++ b/hgext/convert/convcmd.py	Fri Feb 14 11:22:52 2014 +1100
@@ -103,12 +103,15 @@ 
         self.commitcache = {}
         self.authors = {}
         self.authorfile = None
+        self.authormapsuffix = ''
 
         # Record converted revisions persistently: maps source revision
         # ID to target revision ID (both strings).  (This is how
         # incremental conversions work.)
         self.map = mapfile(ui, revmapfile)
 
+        if opts.get('authormapsuffix'):
+            self.authormapsuffix = opts.get('authormapsuffix')
         # Read first the dst author map if any
         authorfile = self.dest.authorfile()
         if authorfile and os.path.exists(authorfile):
@@ -393,7 +396,7 @@ 
                 continue
 
             srcauthor = srcauthor.strip()
-            dstauthor = dstauthor.strip()
+            dstauthor = dstauthor.strip() + self.authormapsuffix
             if self.authors.get(srcauthor) in (None, dstauthor):
                 msg = _('mapping author %s to %s\n')
                 self.ui.debug(msg % (srcauthor, dstauthor))
@@ -407,7 +410,8 @@ 
 
     def cachecommit(self, rev):
         commit = self.source.getcommit(rev)
-        commit.author = self.authors.get(commit.author, commit.author)
+        commit.author = self.authors.get(commit.author,
+                                         commit.author + self.authormapsuffix)
         # If commit.branch is None, this commit is coming from the source
         # repository's default branch and destined for the default branch in the
         # destination repository. For such commits, passing a literal "None"
diff -r 80628d4069be -r 2b6fdac02ea3 tests/test-convert-authormap.t
--- a/tests/test-convert-authormap.t	Fri Jan 31 01:12:35 2014 -0800
+++ b/tests/test-convert-authormap.t	Fri Feb 14 11:22:52 2014 +1100
@@ -10,6 +10,8 @@ 
   $ cd orig
   $ echo foo > foo
   $ HGUSER='user name' hg ci -qAm 'foo'
+  $ echo bar > bar
+  $ HGUSER='user name 2' hg ci -qAm 'bar'
   $ cd ..
 
 Explicit --authors
@@ -26,13 +28,19 @@ 
   scanning source...
   sorting...
   converting...
-  0 foo
+  1 foo
+  0 bar
   writing author map file $TESTTMP/new/.hg/authormap (glob)
   $ cat new/.hg/authormap
   user name=Long User Name
   $ hg -Rnew log
+  changeset:   1:263e7765e4b7
+  tag:         tip
+  user:        user name 2
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     bar
+  
   changeset:   0:d89716e88087
-  tag:         tip
   user:        Long User Name
   date:        Thu Jan 01 00:00:00 1970 +0000
   summary:     foo
@@ -48,11 +56,73 @@ 
   scanning source...
   sorting...
   converting...
-  0 foo
+  1 foo
+  0 bar
   $ hg -Rnew log
+  changeset:   1:263e7765e4b7
+  tag:         tip
+  user:        user name 2
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     bar
+  
   changeset:   0:d89716e88087
-  tag:         tip
   user:        Long User Name
   date:        Thu Jan 01 00:00:00 1970 +0000
   summary:     foo
   
+  $ rm -rf new
+
+Use authormapsuffix together with authormap
+
+  $ cat > authormap.txt <<EOF
+  > user name = username
+  > user name 2 = username2
+  > EOF
+  $ hg convert --authormap authormap.txt --authormapsuffix '@test.org' orig new
+  initializing destination new repository
+  scanning source...
+  sorting...
+  converting...
+  1 foo
+  0 bar
+  writing author map file $TESTTMP/new/.hg/authormap
+  $ cat new/.hg/authormap
+  user name=username@test.org
+  user name 2=username2@test.org
+  $ hg -Rnew log
+  changeset:   1:aeeaab422b32
+  tag:         tip
+  user:        username2@test.org
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     bar
+  
+  changeset:   0:51317d63da9e
+  user:        username@test.org
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     foo
+  
+  $ rm -rf new
+
+Use authormapsuffix stand alone
+
+  $ hg convert --authormapsuffix '@test.org' orig new
+  initializing destination new repository
+  scanning source...
+  sorting...
+  converting...
+  1 foo
+  0 bar
+  $ hg -Rnew log
+  changeset:   1:94e0dcfe3b0d
+  tag:         tip
+  user:        user name 2@test.org
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     bar
+  
+  changeset:   0:e2ff155c86b8
+  user:        user name@test.org
+  date:        Thu Jan 01 00:00:00 1970 +0000
+  summary:     foo
+  
+  $ rm -rf new
+