[VOTE] git versus mercurial

[Arne Babenhauserheide-2]

Am Dienstag 28 Oktober 2008 18:48:28 schrieb Andreas Ericsson:
> > Stuff which does command line parsing can naturally break when I change
> > the output. But it can also directly use the advanced features.
>
> But then you're back with a single language, taking valuable freedom
> away from the addon author.

Not really.

Extension authors just have to take care to keep their output compatible.

You can do command line parsing just like with git, but additionally you can
change the workings of the basic commands, but then you have to take care to
keep the output compatible.

For example when I wrote the group extension, I made sure that the log only
gives grouped output, when it is explicitely asked to do so, either via
--group or via the grouped_log=True setting in .hgrc.

> How many perl gurus have skipped writing
> stuff for hg because it's a "python-or-bust" thing?

How many Python people decided to write an extension for hg, because it can
very nicely be accessed via Python?

(and which one of these has the higher effect? :) )

Best wishes,
Arne


-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

[Miklos Vajna]

On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie <[hidden email]> wrote:
> fast-import yet. If I understand dscho correctly, that exists now, so it
> should be easy enough to integrate that as well.

That's new to me. Theodore Ts'o once mentioned on this list that there
is a "hg fast-export" but actually he just referred to "there is a
git2hg conversion tool in hg's contrib dir" and it has nothing with
fast-import.

There is an other reference to hg fast-import:

http://www.nabble.com/cvs2git-2.1-causes-git-fast-import-to-exit-with-an-error-td16049922.html

but I found no code so far.

To sum up, I'm not so sure about a working hg fast-import is available
at the moment.

[Randal L. Schwartz]

>>>>> "Andreas" == Andreas Ericsson <[hidden email]> writes:

Andreas> And please don't give me that rubbish of "but Python is obviously
Andreas> better than C". Which one's true (if any) depends only on how you
Andreas> define "better".

But any way you define it, Perl is "better" than either of those!

:-)


--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - [phone]
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[SZEDER Gábor]

On Tue, Oct 28, 2008 at 08:11:36PM +0100, Arne Babenhauserheide wrote:
> > How many perl gurus have skipped writing
> > stuff for hg because it's a "python-or-bust" thing?
>
> How many Python people decided to write an extension for hg, because it can
> very nicely be accessed via Python?

And wouldn't they contribute at all, if there would be hg bindings for
other programming languages, would they?


Best,
Gábor
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Miklos Vajna]

On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna <[hidden email]> wrote:
> To sum up, I'm not so sure about a working hg fast-import is available
> at the moment.

I wrote too fast.

There is a minimal implementation here:

http://hg.opensource.lshift.net/hg-fastimport/

(I haven't tried it yet myself.)

[Theodore Tso]

On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna wrote:
> On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie <[hidden email]> wrote:
> > fast-import yet. If I understand dscho correctly, that exists now, so it
> > should be easy enough to integrate that as well.
>
> That's new to me. Theodore Ts'o once mentioned on this list that there
> is a "hg fast-export" but actually he just referred to "there is a
> git2hg conversion tool in hg's contrib dir" and it has nothing with
> fast-import.

The code I was referring to was called hg-fast-export, which is part
of the "fast export" tools that front-end into git fast-import.  The
git repository can be found here:

        http://repo.or.cz/w/fast-export.git
        git://repo.or.cz/fast-export.git

I ended up using a very customized version of that script to convert
the hg e2fsprogs repository to git.

In the past I've looked at the possibility of creating a
bi-directional, incremental gateway between hg and git repositories.
The main thing which makes this difficult is that hg stores tags
in-band inside the change-controlled .hgtags file.  This means that if
you cut a release, tag it, and then create a commit to further modify
the repository, the new commit is descended from the tag commit,
whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
but not part of the revision history.

I think the git method is much more sane, but what it means is that
topologically, the commit tree for git and hg can never be identical.
It also means that if you add a tag to a git tree after making several
commits on that branch, how you reflect that in the hg repository is
highly problematic.  Do you rewrite the branch?  Do you add the tag
later on, disturbing the parent-child relationship of later commits?
How do you keep track of when a tag hg repository topology if you are
trying to maintain a bidirectional mapping between commits?

It's not impossible, but it makes it much more difficult, since in the
hg world, tag commits can be inserted between arbitrary commits.  This
also means that if you want to create a bidrectional gateway between
hg and git, it has to be a single gateway so it can keep track of this
state information.  If you try to have multiple gateways they would
need to synchronize on when a tag entered the hg universe, and with
what commit ID (and what timestamp).

                                                - Ted
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Miklos Vajna]

On Tue, Oct 28, 2008 at 05:31:44PM -0400, Theodore Tso <[hidden email]> wrote:
> The code I was referring to was called hg-fast-export, which is part
> of the "fast export" tools that front-end into git fast-import.  The
> git repository can be found here:
>
> http://repo.or.cz/w/fast-export.git
> git://repo.or.cz/fast-export.git
>
> I ended up using a very customized version of that script to convert
> the hg e2fsprogs repository to git.

My bad, I did not quote the article properly, so here is what I meant:

http://article.gmane.org/gmane.comp.version-control.git/42298

and I just wanted to say that this one does not use fast-import, so it's
not really a "hg-fast-import" (it's not something that can parse the
output of git-fast-export).

[Miles Bader-2]

walt <[hidden email]> writes:
> The official vote was 19 to 19, plus one for perforce and one
> for svn.  Matt has proposed a primary git repository and a mirror
> in hg, and that's being debated now.

Boy, whoever has the popcorn concession must be making a fortune!

-Miles

--
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Shawn O. Pearce]

Johannes Schindelin <[hidden email]> wrote:

> On Tue, 28 Oct 2008, walt wrote:
>
> > walt wrote:
> > > No, no, I'm not the one calling for a vote.  You old-timers here will
> > > know the name Matt Dillon, who is leading the dragonflybsd project
> > > (www.dragonflybsd.org).
> > >
> > > Matt is the one who is calling for the vote in his thread "Vote for
> > > your source control system" in the dragonfly.kernel group, accessible
> > > via nntp://nntp.dragonflybsd.org...
> >
> > The official vote was 19 to 19, plus one for perforce and one for svn.  
> > Matt has proposed a primary git repository and a mirror in hg, and
> > that's being debated now.

FWIW at the Google Summer of Code Mentor Summit this past weekend
we had a "Git vs. Hg" talk with both Git and Hg represented by
contributors to each project.

Slides are online here:

  http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr

--
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Boyd Lynn Gerber]

On Wed, 29 Oct 2008, Shawn O. Pearce wrote:

> Johannes Schindelin <[hidden email]> wrote:
>> On Tue, 28 Oct 2008, walt wrote:
>>> walt wrote:
>>>> No, no, I'm not the one calling for a vote.  You old-timers here will
>>>> know the name Matt Dillon, who is leading the dragonflybsd project
>>>> (www.dragonflybsd.org).
>>>>
>>>> Matt is the one who is calling for the vote in his thread "Vote for
>>>> your source control system" in the dragonfly.kernel group, accessible
>>>> via nntp://nntp.dragonflybsd.org...
>>>
>>> The official vote was 19 to 19, plus one for perforce and one for svn.
>>> Matt has proposed a primary git repository and a mirror in hg, and
>>> that's being debated now.
>
> FWIW at the Google Summer of Code Mentor Summit this past weekend
> we had a "Git vs. Hg" talk with both Git and Hg represented by
> contributors to each project.
>
> Slides are online here:
>
>  http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr

But how do I save the presentation?  I do not seem to be able to do it.  I
would like to view it off-line.

Thanks,

--
Boyd Gerber <[hidden email]>
ZENEZ 1042 East Fort Union #135, Midvale Utah  84047
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Johannes Schindelin]

Hi,

On Wed, 29 Oct 2008, Boyd Lynn Gerber wrote:

> On Wed, 29 Oct 2008, Shawn O. Pearce wrote:
> > Johannes Schindelin <[hidden email]> wrote:
> > > On Tue, 28 Oct 2008, walt wrote:
> > > > walt wrote:
> > > > > No, no, I'm not the one calling for a vote.  You old-timers here
> > > > > will know the name Matt Dillon, who is leading the dragonflybsd
> > > > > project (www.dragonflybsd.org).
> > > > >
> > > > > Matt is the one who is calling for the vote in his thread "Vote
> > > > > for your source control system" in the dragonfly.kernel group,
> > > > > accessible via nntp://nntp.dragonflybsd.org...
> > > >
> > > > The official vote was 19 to 19, plus one for perforce and one for
> > > > svn. Matt has proposed a primary git repository and a mirror in
> > > > hg, and that's being debated now.
> >
> > FWIW at the Google Summer of Code Mentor Summit this past weekend we
> > had a "Git vs. Hg" talk with both Git and Hg represented by
> > contributors to each project.
> >
> > Slides are online here:
> >
> >  http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr
>
> But how do I save the presentation?  I do not seem to be able to do it.  
> I would like to view it off-line.

Just an idea: print to PDF?  There is a link "print slides" on the lower
right.

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Boyd Lynn Gerber]

On Wed, 29 Oct 2008, Johannes Schindelin wrote:

> On Wed, 29 Oct 2008, Boyd Lynn Gerber wrote:
>> On Wed, 29 Oct 2008, Shawn O. Pearce wrote:
>>> Johannes Schindelin <[hidden email]> wrote:
>>>> On Tue, 28 Oct 2008, walt wrote:
>>>>> walt wrote:
>>>>>> No, no, I'm not the one calling for a vote.  You old-timers here
>>>>>> will know the name Matt Dillon, who is leading the dragonflybsd
>>>>>> project (www.dragonflybsd.org).
>>>>>>
>>>>>> Matt is the one who is calling for the vote in his thread "Vote
>>>>>> for your source control system" in the dragonfly.kernel group,
>>>>>> accessible via nntp://nntp.dragonflybsd.org...
>>>>>
>>>>> The official vote was 19 to 19, plus one for perforce and one for
>>>>> svn. Matt has proposed a primary git repository and a mirror in
>>>>> hg, and that's being debated now.
>>>
>>> FWIW at the Google Summer of Code Mentor Summit this past weekend we
>>> had a "Git vs. Hg" talk with both Git and Hg represented by
>>> contributors to each project.
>>>
>>> Slides are online here:
>>>
>>>  http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr
>>
>> But how do I save the presentation?  I do not seem to be able to do it.
>> I would like to view it off-line.
>
> Just an idea: print to PDF?  There is a link "print slides" on the lower
> right.

That worked.  I had to make my window full screen to see the option.  It
did not show-up in my normal window.


Thanks,

--
Boyd Gerber <[hidden email]>
ZENEZ 1042 East Fort Union #135, Midvale Utah  84047
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Florian Weimer]

* Theodore Tso:

> In the past I've looked at the possibility of creating a
> bi-directional, incremental gateway between hg and git repositories.
> The main thing which makes this difficult is that hg stores tags
> in-band inside the change-controlled .hgtags file.  This means that if
> you cut a release, tag it, and then create a commit to further modify
> the repository, the new commit is descended from the tag commit,
> whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
> but not part of the revision history.

Couldn't you just keep the .hgtags file and have everyone interested
in the tags use special scripts?

(Admittedly, I'm horribly totally by Git's behavior in this area.  I
haven't figured out yet under what circumstances tags are pushed and
pulled, so I'm not totally opposed to the Mercurial model. 8-/)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Santi Béjar-2]

On Sat, Nov 1, 2008 at 9:06 AM, Florian Weimer <[hidden email]> wrote:
>
> (Admittedly, I'm horribly totally by Git's behavior in this area.  I
> haven't figured out yet under what circumstances tags are pushed and
> pulled, so I'm not totally opposed to the Mercurial model. 8-/)

Tag are pushed when you tell it so, and pulled if they are pointing to
the history you have, or you can ask to fetch them explicitly.

HTH,
Santi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Peter Krefting]

Hi!

Pieter de Bie:

> What would you want that the fast-export/imports are lacking? I think
> they are excellent tools to build some integration on.

Speed. I am cloning from a rather overloaded server on the other side
of the globe (the US). If I were to go the fast-export/import route, I
fear it would take even longer.

> You might want to look at my git-bzr script

Looks very interesting. *adding to my things-to-examine list*

--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jakub Narebski]

Florian Weimer <[hidden email]> writes:

> * Theodore Tso:
>
> > In the past I've looked at the possibility of creating a
> > bi-directional, incremental gateway between hg and git repositories.
> > The main thing which makes this difficult is that hg stores tags
> > in-band inside the change-controlled .hgtags file.  This means that if
> > you cut a release, tag it, and then create a commit to further modify
> > the repository, the new commit is descended from the tag commit,
> > whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
> > but not part of the revision history.
>
> Couldn't you just keep the .hgtags file and have everyone interested
> in the tags use special scripts?
>
> (Admittedly, I'm horribly totally by Git's behavior in this area.  I
> haven't figured out yet under what circumstances tags are pushed and
> pulled, so I'm not totally opposed to the Mercurial model. 8-/)

I think you don't understand the issue here.

First, I think that we all agree here that by definition tags should
named reference (for example 'v1.0' or '1.0') to some immutable
snapshot of a state of repository, so for example when somebody says
'v1.0' everybody knows what it is.  In Git tags are immutable (you
can't checkout a tag, you can only checkout state pointed by tag)
external pointers to commits in the DAG (graph) of revisions.

Global tags (tags used to mark releases like 'v1.0') have to _not
versioned_ and _transferable_.  Transferable (global) because we want
to know for example what 'v1.0' version was in each clone / each
repository.  Non-versioned because we want to have the same set of
tags independent on what branch we are (when we are on 'master', we
want to be able to know about 'v1.0.1' which is on 'maint'), and what
revision we have checked out (for example during bisection, we want to
be able to compare to 'v1.0' even if we have checked out revision
which is earlier than 'v1.0').

Do you agree that global tags should be both non-versioned and
trasferable?

Now Mercurial has chosen to use in-tree '.hgtags' file to have global
tags transferable.  Never mind the fact that it had to treat this file
in special way to have it non-versioned (as opposed to for example
.*ignore file, which should be both transferable and versioned); the
fact that in-tree file is used means that tag is visible to outside
(transferable) only after you commit changes in .hgtags file.

In Git tags are external to object database; they reside in
refs/tags/* namespace.  They are of course non-versioned, as not being
in-tree.  In default configuration however (from what I understand) if
you transfer (get) some tagged commit, you also get a tag that points
to transferred commit.  You don't need to create "PROJECT 1.0" (or
"Tagged v1.0") commit to make tag visible to outside.


In short, if you want to have bi-directional gateway between Mercurial
and Git, Git has to be limited:
 * no octopus merges (with more than two parents)
 * always create 'tagging commits' (bump version number for example)
   for tagging purposes on Mercurial side.

--
Jakub Narebski
Poland
ShadeHawk on #git
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Florian Weimer]

* Jakub Narebski:

> Florian Weimer <[hidden email]> writes:
>> * Theodore Tso:
>>
>> > In the past I've looked at the possibility of creating a
>> > bi-directional, incremental gateway between hg and git repositories.
>> > The main thing which makes this difficult is that hg stores tags
>> > in-band inside the change-controlled .hgtags file.  This means that if
>> > you cut a release, tag it, and then create a commit to further modify
>> > the repository, the new commit is descended from the tag commit,
>> > whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
>> > but not part of the revision history.
>>
>> Couldn't you just keep the .hgtags file and have everyone interested
>> in the tags use special scripts?
>>
>> (Admittedly, I'm horribly totally by Git's behavior in this area.  I
>> haven't figured out yet under what circumstances tags are pushed and
>> pulled, so I'm not totally opposed to the Mercurial model. 8-/)
>
> I think you don't understand the issue here.

Probably yes.

> Do you agree that global tags should be both non-versioned and
> trasferable?

Yes, I do.  In case of Git, I've got trouble with understanding how to
actually implement the "transferable" part with Git.  The Mercurial
way is easier to understand, but it means that tags may need some sort
of "tag at this revision" qualifier to disambiguate, which is rather
problematic.

> Now Mercurial has chosen to use in-tree '.hgtags' file to have global
> tags transferable.  Never mind the fact that it had to treat this file
> in special way to have it non-versioned

Oops, thought this file was versioned.  Things like

  <http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>

suggest it was at some point.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Florian Weimer]

* Florian Weimer:

>> Now Mercurial has chosen to use in-tree '.hgtags' file to have global
>> tags transferable.  Never mind the fact that it had to treat this file
>> in special way to have it non-versioned
>
> Oops, thought this file was versioned.  Things like
>
>   <http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>
>
> suggest it was at some point.

Okay, checked it--.hgtags files are in fact versioned.  So my
suggestion to preserve the .hgtags file on the Git side remains.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jakub Narebski]

On Sat, 1 Nov 2008, Florian Weimer wrote:

> * Jakub Narebski:
>> Florian Weimer <[hidden email]> writes:
>>> * Theodore Tso:
>>>
>>>> In the past I've looked at the possibility of creating a
>>>> bi-directional, incremental gateway between hg and git repositories.
>>>> The main thing which makes this difficult is that hg stores tags
>>>> in-band inside the change-controlled .hgtags file.  This means that if
>>>> you cut a release, tag it, and then create a commit to further modify
>>>> the repository, the new commit is descended from the tag commit,
>>>> whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
>>>> but not part of the revision history.
>>>
>>> Couldn't you just keep the .hgtags file and have everyone interested
>>> in the tags use special scripts?
>>>
>>> (Admittedly, I'm horribly totally by Git's behavior in this area.  I
>>> haven't figured out yet under what circumstances tags are pushed and
>>> pulled, so I'm not totally opposed to the Mercurial model. 8-/)

>> Do you agree that global tags should be both non-versioned and
>> trasferable?
>
> Yes, I do.  In case of Git, I've got trouble with understanding how to
> actually implement the "transferable" part with Git.  The Mercurial
> way is easier to understand, but it means that tags may need some sort
> of "tag at this revision" qualifier to disambiguate, which is rather
> problematic.

In first page of git-fetch(1):

     When <refspec> stores the fetched result in  tracking  branches,  the  tags
     that  point  at  these branches are automatically followed. This is done by
     first fetching from the remote using  the  given  <refspec>s,  and  if  the
     repository has objects that are pointed by remote tags that it does not yet
     have, then fetch those missing tags. If the other end has tags  that  point
     at branches you are not interested in, you will not get them.

You push tags explicitly (using "tag <tagname>" refspec, or specifying
--tags, --all or --mirror, or setting it up in a config) in git.
 
>> Now Mercurial has chosen to use in-tree '.hgtags' file to have global
>> tags transferable.  Never mind the fact that it had to treat this file
>> in special way to have it non-versioned
>
> Oops, thought this file was versioned.  Things like
>
>   <http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>
>
> suggest it was at some point.

It is half-versioned... :-X  From what I remember of discussion on
#revctrl and reading hgbok it is treated in special way: if you
switch branches or rewind to some older version, .hgtags is always
checked out the most recent version.

I don't know how Mercurial deals with situation where one reposityr
added one tag, and other repository add other...

--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Theodore Tso]

On Sat, Nov 01, 2008 at 11:44:21AM +0100, Florian Weimer wrote:
> > Now Mercurial has chosen to use in-tree '.hgtags' file to have global
> > tags transferable.  Never mind the fact that it had to treat this file
> > in special way to have it non-versioned
>
> Oops, thought this file was versioned.  Things like
>
>   <http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>

.hgtags is stored as a versioned file in Mercurial.  That's one of the
problems, and it leads to no shortage of headaches.

Some of the problems are discussed here:

   http://www.selenic.com/mercurial/wiki/index.cgi/Tag

Specifically, to quote the Mercurial Wiki:

    The fact that tags identify changesets and are also parts of
    changesets has some potentially confusing implications:

    * The changeset that a tag refers to is always older than the
      changeset that commits the tag itself.

    * Updating a working dir to a particular tag will take that
      directory back to a point before the tag itself existed.

    * Cloning a repo to a particular tag will give you a new repo that
      does not have that tag.

In addition, Mercurial has to play interesting special case games in a
repository which has multiple heads (in git terms, "branches").  When
looking up a tag, it has to take the union of all of the .hgtags files
at the tips of each of the branches.  So if you have a large number of
heads in your Mercurial repository, tags access doesn't scale well at
all.  Mercurial is very much optimized for having a single or at best
a few heads/branches in a repository.

As I mentioned earlier this makes it much more difficult to do a
bidrectional hg/git gateway, since the two DAG's are not toplogically
equivalent, and in fact, *when* you add a tag to a particular
commit/revision can make a distinct difference to the shape of the
DAG.  If you tag right after creating the revision in question, then
there is a tag commit right after the revision.  If you commit a few
dozen changes into the repository, and *then* tag a point many commits
earlier, then the tag commit will be tacked onto the head of whatever
branch you happened to be on.

In fact, in the worst case, if you accidentally tag a revision on the
"maint" branch while you happened to be on the "devel" branch, the tag
for the commit in the "maint" branch will be attached to the "devel"
branch, and while it will work just fine for *you*, someone who only
fetches the "maint" branch might never see the tag that you placed on
the maint branch --- unless they happen to also pull the devel branch.

What fun, eh?

                                        - Ted
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html