git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Jakub Narebski <jnareb@gmail.com>, git@vger.kernel.org
Subject: Re: Git/Mercurial interoperability (and what about bzr?)
Date: Sat, 1 Nov 2008 09:39:31 -0400	[thread overview]
Message-ID: <20081101133931.GC8134@mit.edu> (raw)
In-Reply-To: <87abcjpvy2.fsf@mid.deneb.enyo.de>

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

  parent reply	other threads:[~2008-11-01 13:41 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-26  4:28 [VOTE] git versus mercurial walt
2008-10-26 14:15 ` [VOTE] git versus mercurial (for DragonflyBSD) Jakub Narebski
2008-10-26 14:30   ` Maxim Vuets
2008-10-26 15:05     ` Leo Razoumov
2008-10-26 18:55       ` Jakub Narebski
2008-10-27  0:20         ` Arne Babenhauserheide
2008-10-27  4:15           ` Leo Razoumov
2008-10-27  7:16             ` Arne Babenhauserheide
2008-10-27  7:16             ` dhruva
2008-10-27  0:47         ` Arne Babenhauserheide
2008-10-27  1:52           ` Jakub Narebski
2008-10-27  7:50             ` Arne Babenhauserheide
2008-10-27  9:41               ` Jakub Narebski
2008-10-27 10:12                 ` Leslie P. Polzer
2008-10-27 10:14                 ` Arne Babenhauserheide
2008-10-27 12:48                   ` Jakub Narebski
     [not found]                     ` <200810271512.26352.arne_bab@web.de>
2008-10-27 18:01                       ` Jakub Narebski
2008-10-27 20:48                         ` Arne Babenhauserheide
2008-10-27 21:07                           ` Miklos Vajna
2008-10-27 21:30                             ` Arne Babenhauserheide
2008-10-28  0:13                               ` Miklos Vajna
2008-10-28 17:48                               ` Andreas Ericsson
2008-10-28 19:11                                 ` Arne Babenhauserheide
2008-10-28 19:38                                   ` SZEDER Gábor
2008-11-06 16:25                                     ` Marcin Kasperski
2008-11-06 17:41                                       ` Isaac Jurado
2008-10-28 19:16                                 ` Randal L. Schwartz
2008-10-27 23:25                           ` Jakub Narebski
2008-10-27  9:29             ` Benoit Boissinot
2008-10-27 10:57               ` Jakub Narebski
2008-10-27 14:29                 ` 0000 vk
2008-10-27 14:57                   ` Jakub Narebski
     [not found]             ` <1225100597.31813.11.camel@abelardo.lan>
2008-10-27 11:42               ` David Soria Parra
2008-10-27 20:07             ` Brandon Casey
2008-10-27 20:37               ` Jakub Narebski
2008-10-28  1:28                 ` Nicolas Pitre
2008-10-26 15:57   ` Felipe Contreras
2008-10-26 19:07     ` Jakub Narebski
2008-10-26 19:54       ` Felipe Contreras
2008-10-28 12:31 ` [VOTE] git versus mercurial walt
2008-10-28 14:28   ` Johannes Schindelin
2008-10-28 14:41     ` Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial) Peter Krefting
2008-10-28 14:59       ` Johannes Schindelin
2008-10-28 15:02         ` Git/Mercurial interoperability (and what about bzr?) Matthieu Moy
2008-10-28 15:03       ` Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial) Nicolas Pitre
2008-10-28 15:33       ` Pieter de Bie
2008-10-28 19:12         ` Miklos Vajna
2008-10-28 21:10           ` Miklos Vajna
2008-10-28 21:31           ` Theodore Tso
2008-10-28 23:28             ` Miklos Vajna
2008-11-01  8:06             ` Git/Mercurial interoperability (and what about bzr?) Florian Weimer
2008-11-01 10:03               ` Santi Béjar
2008-11-01 10:33               ` Jakub Narebski
2008-11-01 10:44                 ` Florian Weimer
2008-11-01 11:10                   ` Florian Weimer
2008-11-01 12:26                   ` Jakub Narebski
2008-11-01 13:39                   ` Theodore Tso [this message]
2008-11-01 17:51                     ` Linus Torvalds
2008-11-02  1:13                       ` Theodore Tso
2008-11-01 10:16         ` Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial) Peter Krefting
2008-10-29 19:11     ` [VOTE] git versus mercurial Shawn O. Pearce
2008-10-29 19:36       ` Boyd Lynn Gerber
2008-10-29 19:48         ` Johannes Schindelin
2008-10-29 19:51           ` Boyd Lynn Gerber
2008-10-29  8:15   ` Miles Bader

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081101133931.GC8134@mit.edu \
    --to=tytso@mit.edu \
    --cc=fw@deneb.enyo.de \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).