git-svn: multiple fetch lines

git-svn: multiple fetch lines

[Nathan Gray]

Hello,

I'm in a conversation with the support fellow of the very nice Tower
git interface for OS X and we need clarification on a point.  Does
git-svn explicitly support multiple "fetch =" lines in an svn-remote
section or is it just an accident that it works?  My belief is that
such support is intended and his is that it is accidental.

You can see a more detailed explanation of why you would want to use
multiple fetch lines on this fellow's blog post:

http://davegoodell.blogspot.com/2009/04/multiple-remote-branches-in-git-svn.html

My company's svn server layout is a bit of a mess and to work around
that I've been using multiple "fetch" lines in git-svn's config:

[svn-remote "svn"]
    url = https://...

    # The trunk
    fetch = foo/trunk/Product:refs/remotes/trunk

    # Some individual branches from messy directories that I can't use globs on
    fetch = foo/branches/Developers/Nathan/Project/Product:refs/remotes/product-orig
    fetch = foo/branches/august-demo/Product:refs/remotes/august-demo

    # A well-organized branches folder that I can use a glob for
    branches = foo/branches/Product/*:refs/remotes/branches/*

    # etc...

Tower doesn't currently support such configurations and I'd like to
convince them that this is a perfectly sensible thing to do.

Thanks,
-Nathan

-- 
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org

Re: git-svn: multiple fetch lines

[Jonathan Nieder]

Hi Nathan,

Nathan Gray wrote:

> I'm in a conversation with the support fellow of the very nice Tower
> git interface for OS X and we need clarification on a point.  Does
> git-svn explicitly support multiple "fetch =" lines in an svn-remote
> section or is it just an accident that it works?  My belief is that
> such support is intended and his is that it is accidental.

It's true that the documentation is not as clear about this as one
might like.  Documentation/git-svn.txt leaves it to the reader to
infer that this is supported by analogy with "fetch =" lines in native
git [remote] sections:

	'git svn' stores [svn-remote] configuration information in the
	repository .git/config file.  It is similar the core git
	[remote] sections except 'fetch' keys do not accept glob
	arguments; but they are instead handled by the 'branches'
	and 'tags' keys.

The change description for the patch that introduced that functionality
is more helpful.

	$ git log -S'Could not find a \"svn-remote.*.fetch\" key' git-svn.perl
	commit 706587fc
	Author: Eric Wong <normalperson@yhbt.net>
	Date:   Thu Jan 18 17:50:01 2007 -0800

	    git-svn: add support for metadata in .git/config
	    
	    Of course, we handle metadata migrations from previous versions
	    and we have added unit tests.
	    
	    The new .git/config remotes resemble non-SVN remotes.  Below
	    is an example with comments:
[example using multiple 'fetch' keys snipped]

Perhaps such an example would be useful for the git-svn(1) manpage,
too.  Any ideas for where to add such a note, and how it should be
worded?  (Of course, if you can phrase such an idea in patch form,
that would be the most convenient.)

Hope that helps,
Jonathan

Re: git-svn: multiple fetch lines

[Nathan Gray]

Hi,

On Sat, Dec 17, 2011 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Nathan,
>
> Nathan Gray wrote:
>
>> I'm in a conversation with the support fellow of the very nice Tower
>> git interface for OS X and we need clarification on a point.  Does
>> git-svn explicitly support multiple "fetch =" lines in an svn-remote
>> section or is it just an accident that it works?  My belief is that
>> such support is intended and his is that it is accidental.
>
> It's true that the documentation is not as clear about this as one
> might like.  Documentation/git-svn.txt leaves it to the reader to
> infer that this is supported by analogy with "fetch =" lines in native
> git [remote] sections:

Thanks Jonathan, that's just what I suspected.

[snip]

> Perhaps such an example would be useful for the git-svn(1) manpage,
> too.  Any ideas for where to add such a note, and how it should be
> worded?  (Of course, if you can phrase such an idea in patch form,
> that would be the most convenient.)

The existing CONFIGURATION section of the man page seems like a
sensible place to mention multiple fetch entries.  I've also found the
documentation on creating branches in the presence of multiple branch
keys to be confusing and in need of an example, so maybe that could go
in as well.  How about something along these lines:

"""
In order to simplify working with messy subversion repositories you
can configure multiple fetch, branches, and tags keys.  For example:

[svn-remote "messy-repo"]
  url = http://server.org/svn
  fetch = trunk/project-a:refs/remotes/project-a/trunk
  fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
  branches = branches/server/*:refs/remotes/project-a/branches/*
  branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
  tags = tags/server/*:refs/remotes/project-a/tags/*

To create a branch in this configuration you need to specify the
location for the new branch using the -d or --destination flag.  For
example:

git svn branch -d wtf-goes-here-anyway?? release-2-3-0
"""

The thing about the -d option that confuses me is that I'm not sure if
I'm supposed to be supplying a full svn path, a partial svn path, the
glob from the config file, etc.  An example would make it obvious.
Personally, I always take the coward's way out and comment out the
extra branches keys, make the branch without -d, then restore them in
order to avoid any potential problems.  :^)

Thanks,
-Nathan

-- 
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org

[RFC/PATCH 0/2] Re: git-svn: multiple fetch lines

[Jonathan Nieder]

Nathan Gray wrote:

> How about something along these lines:

Sounds sensible.  Here's a patch series along those lines to get
things started.  Please feel free to try them (use "make -C
Documentation git-svn.1" to test), tweak to taste, and resend when
ready for Eric to pick up.

Thanks,

Jonathan Nieder (1):
  git-svn: clarify explanation of --destination argument

Nathan Gray (1):
  git-svn: multiple fetch/branches/tags keys are supported

 Documentation/git-svn.txt |   31 ++++++++++++++++++++++++++-----
 1 files changed, 26 insertions(+), 5 deletions(-)

[PATCH 1/2] git-svn: multiple fetch/branches/tags keys are supported

[Jonathan Nieder]

From: Nathan Gray <n8gray@n8gray.org>

"git svn" can be configured to use multiple fetch, branches, and tags
refspecs by passing multiple --branches or --tags options at init time
or editing the configuration file later, which can be handy when
working with messy Subversion repositories.  Add a note to the
configuration section documenting how this works.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 Documentation/git-svn.txt |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 34ee7850..66fd60a4 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -923,6 +923,18 @@ comma-separated list of names within braces. For example:
 	tags = tags/{1.0,2.0}/src:refs/remotes/tags/*
 ------------------------------------------------------------------------
 
+Multiple fetch, branches, and tags keys are supported:
+
+------------------------------------------------------------------------
+[svn-remote "messy-repo"]
+	url = http://server.org/svn
+	fetch = trunk/project-a:refs/remotes/project-a/trunk
+	fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
+	branches = branches/server/*:refs/remotes/project-a/branches/*
+	branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
+	tags = tags/server/*:refs/remotes/project-a/tags/*
+------------------------------------------------------------------------
+
 Note that git-svn keeps track of the highest revision in which a branch
 or tag has appeared. If the subset of branches or tags is changed after
 fetching, then .git/svn/.metadata must be manually edited to remove (or
-- 
1.7.8

Re: [PATCH 1/2] git-svn: multiple fetch/branches/tags keys are supported

[Nathan Gray]

Looks good!  These doc changes will help a lot.

Thanks,
-Nathan

On Mon, Dec 19, 2011 at 5:23 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> From: Nathan Gray <n8gray@n8gray.org>
>
> "git svn" can be configured to use multiple fetch, branches, and tags
> refspecs by passing multiple --branches or --tags options at init time
> or editing the configuration file later, which can be handy when
> working with messy Subversion repositories.  Add a note to the
> configuration section documenting how this works.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
>  Documentation/git-svn.txt |   12 ++++++++++++
>  1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 34ee7850..66fd60a4 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -923,6 +923,18 @@ comma-separated list of names within braces. For example:
>        tags = tags/{1.0,2.0}/src:refs/remotes/tags/*
>  ------------------------------------------------------------------------
>
> +Multiple fetch, branches, and tags keys are supported:
> +
> +------------------------------------------------------------------------
> +[svn-remote "messy-repo"]
> +       url = http://server.org/svn
> +       fetch = trunk/project-a:refs/remotes/project-a/trunk
> +       fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
> +       branches = branches/server/*:refs/remotes/project-a/branches/*
> +       branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
> +       tags = tags/server/*:refs/remotes/project-a/tags/*
> +------------------------------------------------------------------------
> +
>  Note that git-svn keeps track of the highest revision in which a branch
>  or tag has appeared. If the subset of branches or tags is changed after
>  fetching, then .git/svn/.metadata must be manually edited to remove (or
> --
> 1.7.8
>



-- 
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org

[PATCH 2/2] git-svn: clarify explanation of --destination argument

[Jonathan Nieder]

The existing documentation for "-d" does not make it obvious whether
its argument is supposed to be a full svn path, a partial svn path,
the glob from the config file, or what.  Clarify the text and add an
example to get the reader started.

Reported-by: Nathan Gray <n8gray@n8gray.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 Documentation/git-svn.txt |   19 ++++++++++++++-----
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 66fd60a4..a343c261 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -254,13 +254,15 @@ first have already been pushed into SVN.
 	Create a tag by using the tags_subdir instead of the branches_subdir
 	specified during git svn init.
 
--d;;
---destination;;
+-d<path>;;
+--destination=<path>;;
+
 	If more than one --branches (or --tags) option was given to the 'init'
 	or 'clone' command, you must provide the location of the branch (or
-	tag) you wish to create in the SVN repository.  The value of this
-	option must match one of the paths specified by a --branches (or
-	--tags) option.  You can see these paths with the commands
+	tag) you wish to create in the SVN repository.  <path> specifies which
+	path to use to create the branch or tag and should match the pattern
+	on the left-hand side of one of the configured branches or tags
+	refspecs.  You can see these refspecs with the commands
 +
 	git config --get-all svn-remote.<name>.branches
 	git config --get-all svn-remote.<name>.tags
@@ -935,6 +937,13 @@ Multiple fetch, branches, and tags keys are supported:
 	tags = tags/server/*:refs/remotes/project-a/tags/*
 ------------------------------------------------------------------------
 
+Creating a branch in such a configuration requires disambiguating which
+location to use using the -d or --destination flag:
+
+------------------------------------------------------------------------
+$ git svn branch -d branches/server release-2-3-0
+------------------------------------------------------------------------
+
 Note that git-svn keeps track of the highest revision in which a branch
 or tag has appeared. If the subset of branches or tags is changed after
 fetching, then .git/svn/.metadata must be manually edited to remove (or
-- 
1.7.8

[PATCH resend 0/2] git-svn: improve documentation of multiple fetch lines

[Jonathan Nieder]

Hi Eric,

I last sent these patches as an RFC a year and a half or so ago[1].
Nathan seemed to like them and they still seem valid, so thought
I'd resubmit. :)

Thoughts of all kinds welcome, as always.

Jonathan Nieder (1):
  git-svn: clarify explanation of --destination argument

Nathan Gray (1):
  git-svn: multiple fetch/branches/tags keys are supported

 Documentation/git-svn.txt | 31 ++++++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

[1] http://thread.gmane.org/gmane.comp.version-control.git/187312/focus=187489

[PATCH 1/2] git-svn: multiple fetch/branches/tags keys are supported

[Jonathan Nieder]

From: Nathan Gray <n8gray@n8gray.org>
Date: Mon, 19 Dec 2011 19:23:50 -0600

"git svn" can be configured to use multiple fetch, branches, and tags
refspecs by passing multiple --branches or --tags options at init time
or editing the configuration file later, which can be handy when
working with messy Subversion repositories.  Add a note to the
configuration section documenting how this works.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
As before.

 Documentation/git-svn.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 58b6d54..6c0988e 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -1032,6 +1032,18 @@ comma-separated list of names within braces. For example:
 	tags = tags/{1.0,2.0}/src:refs/remotes/tags/*
 ------------------------------------------------------------------------
 
+Multiple fetch, branches, and tags keys are supported:
+
+------------------------------------------------------------------------
+[svn-remote "messy-repo"]
+	url = http://server.org/svn
+	fetch = trunk/project-a:refs/remotes/project-a/trunk
+	fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
+	branches = branches/server/*:refs/remotes/project-a/branches/*
+	branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
+	tags = tags/server/*:refs/remotes/project-a/tags/*
+------------------------------------------------------------------------
+
 Note that git-svn keeps track of the highest revision in which a branch
 or tag has appeared. If the subset of branches or tags is changed after
 fetching, then .git/svn/.metadata must be manually edited to remove (or
-- 
1.8.3.rc1

[PATCH 2/2] git-svn: clarify explanation of --destination argument

[Jonathan Nieder]

Date: Mon, 19 Dec 2011 19:24:30 -0600

The existing documentation for "-d" does not make it obvious whether
its argument is supposed to be a full svn path, a partial svn path,
the glob from the config file, or what.  Clarify the text and add an
example to get the reader started.

Reported-by: Nathan Gray <n8gray@n8gray.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Thanks for reading.

 Documentation/git-svn.txt | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 6c0988e..68c706d 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -271,13 +271,15 @@ first have already been pushed into SVN.
 	Create a tag by using the tags_subdir instead of the branches_subdir
 	specified during git svn init.
 
--d;;
---destination;;
+-d<path>;;
+--destination=<path>;;
+
 	If more than one --branches (or --tags) option was given to the 'init'
 	or 'clone' command, you must provide the location of the branch (or
-	tag) you wish to create in the SVN repository.  The value of this
-	option must match one of the paths specified by a --branches (or
-	--tags) option.  You can see these paths with the commands
+	tag) you wish to create in the SVN repository.  <path> specifies which
+	path to use to create the branch or tag and should match the pattern
+	on the left-hand side of one of the configured branches or tags
+	refspecs.  You can see these refspecs with the commands
 +
 	git config --get-all svn-remote.<name>.branches
 	git config --get-all svn-remote.<name>.tags
@@ -1044,6 +1046,13 @@ Multiple fetch, branches, and tags keys are supported:
 	tags = tags/server/*:refs/remotes/project-a/tags/*
 ------------------------------------------------------------------------
 
+Creating a branch in such a configuration requires disambiguating which
+location to use using the -d or --destination flag:
+
+------------------------------------------------------------------------
+$ git svn branch -d branches/server release-2-3-0
+------------------------------------------------------------------------
+
 Note that git-svn keeps track of the highest revision in which a branch
 or tag has appeared. If the subset of branches or tags is changed after
 fetching, then .git/svn/.metadata must be manually edited to remove (or
-- 
1.8.3.rc1

Re: [PATCH resend 0/2] git-svn: improve documentation of multiple fetch lines

[Eric Wong]

Jonathan Nieder <jrnieder@gmail.com> wrote:
> I last sent these patches as an RFC a year and a half or so ago[1].
> Nathan seemed to like them and they still seem valid, so thought
> I'd resubmit. :)

Thanks, both applied.  Sorry for forgetting :x