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

git-svnimport

From
CWChristian Wiese <morfoh@opensde.org>
Date
Mar 20, 2007, 18:00 UTC
Message-ID
<20070320200011.444bd942@athlon>
Hello folks,

I'd like to use git-svnimport to mirror the subprojects within our svn repository, but I encountered some pitfalls while testing.

Our Layout is like this:
<SVN_Repository_Root>/{subproject-a,subproject-b}/{trunk,branches,tags}

From the documentation of git-svnimport I assumed that I can use: ------------------------------------------------------ $ git-svnimport -v <SVN_Repository_Root>/subproject-a ------------------------------------------------------ to just fetch subproject-a, but the import fails with an error like this: -------snip-------------------------------------------------------------- 40: Unrecognized path: /subproject-b/tags 40: Unrecognized path: /subproject-b/trunk 41: Unrecognized path: /subproject-a/trunk/foo/bar.txt 42: Unrecognized path: /subproject-a/trunk/foo/bar.txt 43: Unrecognized path: /subproject-a/trunk/foo/bar.txt Generating pack... Done counting 0 objects. Nothing new to pack. Removing unused objects 100%... Done. DONE; creating master branch cp: cannot stat `/repos/test/tmp/.git/refs/heads/origin': No such file or directory fatal: master: not a valid SHA1 -------snip--------------------------------------------------------------

What am I doing wrong ?

When I am using: -------------------------------------------------------- $ git-svnimport -v -T subproject-a <SVN_Repository_Root> -------------------------------------------------------- it gets happily imported.

So I have the impression that the described <SVN_repository_URL> in the documentation of git-svnimport is in fact the Repository Root of the svn repo.

For me it looks like git-svnimport makes the assumption that most svn repos are organized in the following way:

<SVN_repository_URL>/{trunk,branches,tags}/{subproject-a,subproject-b}

I have never seen svn repos organized that way if there are more than one project inside a repo, and it is even not recommended by the svn people as we can see here: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.maint.layout

So the assumption of git-svnimport, that trunk, branches and tags are always top-level directories is unlikely the case in most svn deployments. Most subprojects hosted in a svn repo have their own trunk, branches and tags directories.

I think the '-P' option of git-svnimport should rather define the relative path of the subproject from the svn repository root than from a trunk toplevel directory, which is not existing in most cases.

It might be even useful to rename <SVN_repository_URL> to <SVN_Repository_Root>

-P <Path_from_SVN_Repository_Root>
	By default, the whole  repository is imported.
	-P my/proj will import starting only from my/proj.
	This option is useful when you want to import one project from
	a svn repo which hosts multiple projects, that have their own
	trunk, branches and tags directory structure.
<SVN_Repository_Root>/<Path_from_SVN_Repository_Root>/{trunk,branches,tags}

As far as I can see now that would ease the use of git-svnimport a lot and would help people to migrate from svn to git as well.

Any suggestions are highly welcome!

Thanks in advance. Cheers --Chris

Message 1 of 1 in “git-svnimport”
  1. Christian WieseMar 20, 2007

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.