Re: Different svn-id URLs in history

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Oct 8, 2008, 08:32 UTC
Message-ID: <48EC7022.7030707@drmicha.warpmail.net>
In-Reply-To: <48EC546F.7060106@3d-radar.com>

Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:

Show 27 quoted lines

> Michael J Gruber wrote:
>> Knut Eldhuset venit, vidit, dixit 07.10.2008 12:58:
>>> Hi,
>>>
>>> After cloning my svn repository, I notice that the svn-id URL is 
>>> different when going back in history:
>>>
>>> git-svn-id: https://server/trunk@300
>>>
>>> vs
>>>
>>> git-svn-id: https://server/trunk/some_folder/project/src@250
>>>
>> I take this is as an invitation for guesswork (given the amount of
>> details)...
> 
> Sorry about that... I'm confused.
>> You probably have commits which don't follow your usual svn repo layout
>> (trunk/some_folder/project/src) but commit to trunk/ directly. The output of
>>
>> svn log -v -r300 https://server/trunk@300
>> svn log -v -r250 https://server/trunk/some_folder/project/src@250
>>
>> should give some clues.
>>
> 
> Svn log shows that the same path has been modified in both cases. I see

Does "same path" mean:
- same relative to the above paths or
- same absolute path?

Show 14 quoted lines

> something strange in git, though. Our svn repository has about 6500 
> commits, but git shows over 10.000. Further investigation shows that a 
> lot of svn commits have two entries in git. Some branches off of trunk 
> do not start at r1, but off of a duplicate rNNNN. Could this be due to 
> our unhealthy practice of creating branches off of subtrees in svn? By 
> this I mean create a branch off of 
> https://server/trunk/some_folder/project/src instead of 
> https://server/trunk. If so, what can be done to fix this?
> 
> As a sidenote, during git svn clone, I noticed that each time a new 
> branch or tag was discovered, the "scanning" started back at r1. Is this 
> normal? I would think the history before the branch was already 
> imported. Of course, this could maybe be due to the bad branching 
> practice described above.

svn is typically "abused" in the sense that one svn repo is used for separate projects (your subtrees). git-svn can deal with non-standard repo layouts.

I assume you can't share the svn repo publically, can you? So, in order to help you, we would need to know

- the layout of your svn repo: where are trunk, branches and tags, how
did you create branches and tags in svn, are "projects" entirely separate
- your incarnation of git-svn

Michael