git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Branchaud <marcnarc@xiplink.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: git list <git@vger.kernel.org>, normalperson@yhbt.net
Subject: Re: git svn: Supporting multiple branch subdirs?
Date: Mon, 15 Jun 2009 13:29:45 -0400	[thread overview]
Message-ID: <4A368509.9070801@xiplink.com> (raw)
In-Reply-To: <4A339182.1090204@drmicha.warpmail.net>

Michael J Gruber wrote:
> 
> After doing the init with "--branches=stable" (without releng), do
> git config --add svn-remote.svn.branches 'releng/*:refs/remotes/*'
> 
> This gives you two branches refspecs in .git/config (feel free to put
> them in different dirs under remotes if there may be name clashes
> between stable and releng branches).

That doesn't seem to work...

Here's my .git/config file before the first fetch:

[svn-remote "svn"]
        useSvnsyncProps = 1
        ignore-paths = ^[^/]+/(?:cvs2svn|projects|svnadmin|user|vendor.*)
        url = file:///home/marcnarc/Code/FreeBSD-all-mirror/base
        fetch = head:refs/remotes/trunk
        branches = stable/*:refs/remotes/stable/*
        branches = releng/*:refs/remotes/releng/*
        tags = release/*:refs/remotes/tags/*

(Shouldn't that fetch line be head:refs/remots/head, since there's nothing called "trunk" in the svn repo?  I used git-svn init --trunk=head ...)

With this, git-svn seems to be (mostly) ignoring the branches in stable/.  I've run the first fetch past the point where the first stable/ branch is created ("stable/2.0.5"), but in the repository (while the fetch command is still going, BTW, currently somewhere around commit 15,000), I get:

	$ git branch -a
	  remotes/releng/2.0.5
	  remotes/releng/ALPHA_2_0
	  remotes/releng/BETA_2_0
	  remotes/tags/2.0
	  remotes/tags/2.0.5
	  remotes/tags/2.1.0
	  remotes/tags/2.1.0@12369
	  remotes/trunk

At this point, git-svn has passed the commit that created the stable/2.0.5 branch (8869).  Mind you, nothing was ever committed to that branch, so it's basically a tag.  However, remotes/tags/2.0.5 is at svn commit 9201, which is the correct for the releases/2.0.5 tag.  remotes/tags/2.1.0 is also correct for the tagging of the 2.1.0 release.

git-svn has also passed the commit that created the stable/2.1 branch (9211), as well as later commits that only apply to that branch.  AFAICT, remotes/tags/2.1.0@12369 (which is not an actual tag or branch in the svn repo) is the stable/2.1 branch up to commit 12369, but there have been later commits to stable/2.1 since then that git-svn has seen.  Those later commits don't seem to be in the git repository at all.

The releng/* branches look fine, though.

>> - The releng/X.Y branches are created from the stable/X  tree, where X
>> itself doesn't exist from the start.
> 
> Well, I assume X exists at the time of creation of X.Y. That's all that
> is needed.

Yes, that assumption is correct (it seems the 2.x releng branches were created off the trunk, not from a stable/ branch).

>> - FreeBSD likes to make single commits that spans multiple branches.
>> This is usually done as a security patch: One commit can, for example,
>> touch /head, /stable/X, /stable/W, and several branches under /releng.
> 
> I assume that git-svn converts such an svn commit into several git
> commits, one for each affected branch. Since you have a local mirror
> it's easy to try out.

Yep, git-svn does just that.  Nice!

		M.

  reply	other threads:[~2009-06-15 17:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-12 21:46 git svn: Supporting multiple branch subdirs? Marc Branchaud
2009-06-13 11:46 ` Michael J Gruber
2009-06-15 17:29   ` Marc Branchaud [this message]
2009-06-17 14:25     ` Michael J Gruber
2009-06-17 15:25       ` Marc Branchaud
2009-06-18 14:03         ` Michael J Gruber
2009-06-18 14:28           ` Marc Branchaud
2009-06-18 16:00             ` Michael J Gruber
2009-06-18 14:31           ` [MONKEY PATCH] git-svn: allow two branch configurations Michael J Gruber
2009-06-22 14:50             ` Marc Branchaud
2009-06-23 17:02               ` [PATCH] git svn: Support multiple branch and tag paths in the svn repository Marc Branchaud
2009-06-25  9:36                 ` Eric Wong
2009-06-25 22:25                   ` Junio C Hamano
2009-06-26  0:33                     ` Eric Wong
2009-06-26  5:18                       ` Andreas Ericsson
2009-06-26 18:11                         ` Eric Wong
2009-06-26 19:20                   ` Marc Branchaud
2009-06-26 20:49                     ` [PATCH] git svn: Doc update for multiple branch and tag paths Marc Branchaud
2009-06-26 20:57                     ` [PATCH] git svn: Support multiple branch and tag paths in the svn repository Eric Wong
2009-06-26 21:08                       ` [PATCH] git svn: Fix t9138-multiple-branches to use svn_cmd and (cd ...) syntax Marc Branchaud
2009-06-26 21:54                         ` Eric Wong
2009-06-27 15:03                           ` Marc Branchaud
2009-06-27 22:08                             ` Eric Wong

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=4A368509.9070801@xiplink.com \
    --to=marcnarc@xiplink.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=normalperson@yhbt.net \
    /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).