git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* git-svn fetch
@ 2009-05-29 15:09 Doki Pen
  2009-05-29 16:10 ` Michael J Gruber
  0 siblings, 1 reply; 3+ messages in thread
From: Doki Pen @ 2009-05-29 15:09 UTC (permalink / raw
  To: git

I'm sorry if this has been brought up before, I did look through the 
archive and didn't see it.  

I am working with a repo that has about 7000 commits and about 100 
branches/tags.  I've been using git-svn for about 4 months now and love 
it.  The problem I'm experiencing is that everytime a new branch is added, 
git svn fetch seems to download the entire history all the way from r1.  
Is this the expected behavior?  If so, why is that?  Don't we already have 
the old revisions from trunk and other branches?  

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: git-svn fetch
  2009-05-29 15:09 git-svn fetch Doki Pen
@ 2009-05-29 16:10 ` Michael J Gruber
  2009-05-29 20:31   ` doki_pen
  0 siblings, 1 reply; 3+ messages in thread
From: Michael J Gruber @ 2009-05-29 16:10 UTC (permalink / raw
  To: Doki Pen; +Cc: git

Doki Pen venit, vidit, dixit 29.05.2009 17:09:
> I'm sorry if this has been brought up before, I did look through the 
> archive and didn't see it.  
> 
> I am working with a repo that has about 7000 commits and about 100 
> branches/tags.  I've been using git-svn for about 4 months now and love 
> it.  The problem I'm experiencing is that everytime a new branch is added, 
> git svn fetch seems to download the entire history all the way from r1.  
> Is this the expected behavior?  If so, why is that?  Don't we already have 
> the old revisions from trunk and other branches?  
> 

AFAIK git-svn has to go back in order to search for possible earlier
history of $newbranch. For git-svn, the following two scenarios are
basically equivalent:

- a new branch is added to the svn repo
- you change your git-svn config so that a new branch becomes
"interesting" (which had been skipped before)

git-svn treats them the same way ("a branch we don't know about yet"),
because it can't really (reliably) distinguish between them.

Michael

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: git-svn fetch
  2009-05-29 16:10 ` Michael J Gruber
@ 2009-05-29 20:31   ` doki_pen
  0 siblings, 0 replies; 3+ messages in thread
From: doki_pen @ 2009-05-29 20:31 UTC (permalink / raw
  To: Michael J Gruber; +Cc: git

Michael J Gruber wrote:
> Doki Pen venit, vidit, dixit 29.05.2009 17:09:
>   
[snip]
>> The problem I'm experiencing is that everytime a new branch is added, 
>> git svn fetch seems to download the entire history all the way from r1. 
[snip]
>
> AFAIK git-svn has to go back in order to search for possible earlier
> history of $newbranch. For git-svn, the following two scenarios are
> basically equivalent:
>
> - a new branch is added to the svn repo
> - you change your git-svn config so that a new branch becomes
> "interesting" (which had been skipped before)
>
> git-svn treats them the same way ("a branch we don't know about yet"),
> because it can't really (reliably) distinguish between them.
>   

Turns out that in their infinite wisdom, the repo gods laid out the 
structure like this:

/trunk
  /Source
     [THECODE]
  /SomethingElse
  /SomeOtherStuff
/branches
  /BRANCH-1
     [THECODE]
  /...

The problem was I had trunk set to /trunk and not /trunk/Source.  This 
was a bad mistake.  Since I have fixed it git-svn is quite a bit faster!

TY

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-05-29 20:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-29 15:09 git-svn fetch Doki Pen
2009-05-29 16:10 ` Michael J Gruber
2009-05-29 20:31   ` doki_pen

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).