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

Re: Why does git-svn redownload revisions?

From
Brian Gernhardt <benji@silverinsanity.com>
Date
Sep 8, 2010, 17:19 UTC
Message-ID
<B1E94440-DDCA-4C10-A0EE-E08A66DF3D7E@silverinsanity.com>
In-Reply-To
<loom.20100908T181056-819@post.gmane.org>
This happens when you have a tag or branch that is a subdirectory of trunk.  It looks like tags/nano_2_1_1 is a branch off trunk/nano.  Git-svn doesn't recognize that trunk/nano@4248 is a subdirectory of trunk@4248 so it starts downloading the complete history of trunk/nano again.
On Sep 8, 2010, at 12:13 PM, Daniel Trebbien wrote:
Show 8 quoted lines
> The issue is that the fetch runs up to revision 4250, but then mysteriously
> begins redownloading revisions 1 up to four thousand something in importing
> the `nano_2_1_1` tag:
> ...
> r4248 = 7c444dd667b9629ce92a53e8d35ad2d178e5735f (refs/remotes/trunk)
> 	M	nano/ChangeLog
> 	M	nano/configure.ac
> 	M	nano/po/cs.po
Show 14 quoted lines
> 	M	nano/po/fi.po
> 	M	nano/po/zh_CN.po
> r4249 = 6fbad8a00fa067d1e3de913f77db08c6117843c7 (refs/remotes/trunk)
> 	M	nano/NEWS
> r4250 = 704700855e5112d75654e3e7461e896f49e10fd8 (refs/remotes/trunk)
> Found possible branch point: svn://svn.sv.gnu.org/nano/trunk/nano =>
> svn://svn.sv.gnu.org/nano/tags/nano_2_1_1, 4248
> Initializing parent: refs/remotes/tags/nano_2_1_1@4248
> 	A	mkinstalldirs
> 	A	utils.c
> 	A	nano.h
> 	A	global.c
> 	A	configure
> 	A	Makefile.in
I've encountered the same problem when importing other SVN repos.  If nano is the only subdirectory in trunk, you can fix this by changing your .git/config like this:

- fetch = trunk:refs/remotes/trunk + fetch = trunk/nano:refs/remotes/trunk

This will cause issues if nano is not the only directory in trunk (it won't fetch the others) or if you have branches or tags that branch off the full trunk (you get the same problem).
Or you can downloading both trunk and nano as separate branches.  I think it fetches each revision twice, but it will prevent it from downloading the entire history for each subdirectory branch.
 	fetch = trunk:refs/remotes/trunk
+	fetch = trunk/nano:refs/remotes/nano
This will make your history look a little odd since trunk will have every commit that nano does but be a completely separate branch.  (It also seems to confuse `git-svn find-rev`.)
You can also speed imports like this by creating a local mirror with svnsync and using `git svn clone --use-svnsync-props file:///local/mirror`.  This probably isn't a good long term solution, but can be very handy when you're experimenting with getting it right.  Once you have it set up as you like delete svn-remote.svn.useSvnsyncProps, change svn-remote.svn.url to the original URL, and delete the local mirror.
I've been investigating altering the algorithm that finds branch points to understand branching off subdirectories, but haven't had the time.  It's good to know that the Minix 3 repo isn't the only one that does it.
~~ Brian
Previous: Daniel TrebbienNext: Daniel Trebbien
Message 2 of 4 in “Why does git-svn redownload revisions?”
  1. Daniel TrebbienSep 8, 2010
  2. Brian GernhardtSep 8, 2010
  3. Daniel TrebbienSep 8, 2010
  4. Brian GernhardtSep 8, 2010

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.