git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git svn: Supporting multiple branch subdirs?

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Jun 13, 2009, 11:46 UTC
Message-ID
<4A339182.1090204@drmicha.warpmail.net>
In-Reply-To
<4A32CCA5.7040404@xiplink.com>
Marc Branchaud venit, vidit, dixit 12.06.2009 23:46:
Show 25 quoted lines
> Hi,
> 
> I believe I need git-svn to support multiple branch subdirectories.
> 
> The motivation for this is the (partial) gitification of the FreeBSD subversion repository.  FreeBSD doesn't follow the usual branches/tags/trunk pattern.  Instead:
> 
> - FreeBSD's /trunk is called /head.
> 
> - /head is branched into /stable/X subdirs.
> 
> - Each /stable/X branch is sub-branched into /releng/X.Y subirs.
> 
> - /releng/X.Y.Z branches are tagged under /release/foo.
> 
> I'm only looking to get an updatable mirror of their repo -- I don't (yet) need to push changes back to FreeBSD.
> 
> I'd like to modify git-svn to support multiple (at least two) -b parameters, so I could import the FreeBSD repo with something like
> 	git svn init --trunk=head \
> 		--branches=stable \
> 		--branches=releng \
> 		--tags=release \
> 		file:///local/mirror/of/svn.freebsd.org/base/
> 	git svn fetch
> 
> Is this approach wise or even feasible?  A couple of possible show-stoppers I see are:

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).

> 
> - 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.

> 
> - 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.

> 
> If this isn't completely off the wall, I'd appreciate some pointers on the git-svn.perl code.  I've tried searching through the code to see how the -b parameter is handled, but I got lost pretty quickly.  How does the fetch command deal with branches?

I think there's no need to hack git-svn. Let us know how it goes with the two branches configs.

Michael
Previous: Marc BranchaudNext: Marc Branchaud
Message 2 of 23 in “git svn: Supporting multiple branch subdirs?”
  1. Marc BranchaudJun 12, 2009
  2. Michael J GruberJun 13, 2009
  3. Marc BranchaudJun 15, 2009
  4. Michael J GruberJun 17, 2009
  5. Marc BranchaudJun 17, 2009
  6. Michael J GruberJun 18, 2009
  7. Marc BranchaudJun 18, 2009
  8. Michael J GruberJun 18, 2009
  9. git-svn: allow two branch configurationsMichael J Gruber, Jun 18, 2009
  10. Marc BranchaudJun 22, 2009
  11. git svn: Support multiple branch and tag paths in the svn repository.Marc Branchaud, Jun 23, 2009
  12. Eric WongJun 25, 2009
  13. Junio C HamanoJun 25, 2009
  14. Eric WongJun 26, 2009
  15. Andreas EricssonJun 26, 2009
  16. Eric WongJun 26, 2009
  17. Marc BranchaudJun 26, 2009
  18. git svn: Doc update for multiple branch and tag pathsMarc Branchaud, Jun 26, 2009
  19. Eric WongJun 26, 2009
  20. git svn: Fix t9138-multiple-branches to use svn_cmd and (cd ...) syntax.Marc Branchaud, Jun 26, 2009
  21. Eric WongJun 26, 2009
  22. Marc BranchaudJun 27, 2009
  23. Eric WongJun 27, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.