Problem with git-svn

I'm trying to use a Subversion repository with Git. I had great success with many repositories except one. This one live since long time and as been migrated from CVS to Subversion.

The current Subversion repository contains multiple projects. Each project is under /trunk. While trying to import the project PROJ:

  $ git svn clone svn+ssh://myserver/trunk/PROJ

I get:

Initialized empty Git repository in .git/
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path '/trunk/PROJ'
Found possible branch point: svn+ssh://myserver/importfromcvs/trunk =>
svn+ssh://myserver/trunk/PROJ, 48467
Initializing parent: git-svn@48467
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 101, path
'/importfromcvs/trunk'
r9458 = b90789186c85a19a9f32ea6dc8a4259e2eadef67 (git-svn@48467)
        A       file.el

But file.el is not part of this project, it is part of another one on the same Subversion repository. It looks like git-svn get confused at some point. I've been trying to track this down, but since I've never written a single Perl script that's not easy :(

Note that AFAIK each CVS modules have been imported into /importfromcvs/trunk then move into /trunk/<MODULE_NAME>.

r48467 seem ok as a branch point:

<<
------------------------------------------------------------------------
r48468 | svn | 2007-05-09 15:10:54 +0200 (Wed, 09 May 2007) | 1 line
Changed paths:
   D /importfromcvs/trunk
   A /trunk/PROJ (from /importfromcvs/trunk:48467)

Importing module PROJ into SVN.

So I'm looking for hints about the possible problem.

Note that I have tried to reproduce this with a small script (using the same repository structure) but I was not able.

Thanks, Pascal.

On Sun, Dec 16, 2007 at 11:30:04AM +0100, Pascal Obry wrote:

Eric made a fix[1] this week so git-svn won't get confused if e.g. trunk gets deleted and later created (or e.g. moved). Could you check if it also fixes your problem? At least there is some familiarity, because your trunk/PROJ also get moved from outside a path git-svn isn't tracking.

-Peter

[1]: See this thread for more details
     http://thread.gmane.org/gmane.comp.version-control.git/67665

Pete,

This fix is already installed into the Git version I'm using which is:

   git version 1.5.4.rc0.36.g7680

So there is something else...

Thanks, Pascal.

Pascal Obry <pascal@obry.net> wrote:

Hi,

Can you show me the output of `svn log -v -r9458 svn+ssh://myserver/' ?

Thanks.

So did svn+ssh://importfromcvs/trunk/file.el at r9458? If so, git-svn is behaving as expected. If not, can you tell me where "file.el" was at r9458?

Hi Eric,

$ svn log -v -r9458  svn+ssh://myserver/
------------------------------------------------------------------------
r9458 | (no author) | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 1 line
Changed paths:
   A /importfromcvs
   A /importfromcvs/branches
   A /importfromcvs/tags
   A /importfromcvs/trunk

New repository initialized by cvs2svn. ------------------------------------------------------------------------

file.el was not imported at r9458 but at r9459, just after the creation of the /importfromcvs directories above.

------------------------------------------------------------------------
r9459 | author | 1998-04-22 19:07:08 +0200 (Wed, 22 Apr 1998) | 2 lines
Changed paths:
   A /importfromcvs/trunk/file.el

Initial revision

------------------------------------------------------------------------

Thanks, Pascal.

Pascal Obry <pascal.obry@gmail.com> wrote:

Ah, oops, I was off-by-one with the revision number. But git-svn does look to be doing the right thing here, because it followed history into /importfromcvs/trunk/ and file.el was part of it.

Eric,

Yes part of it but before the creation of the /importfromcvs/trunk/ that was moved later as /trunk/PROJ.

In /importfromcvs/trunk/ there was many projects imported. One per one, each time moving it into /trunk/PROJ.

If I look at history of /trunk/PROJ:

   $ svn log svn+ssh://myserver/trunk/PROJ

The last revision is 45775, so I think git-svn should not look past this revision. So I'm very surprised by the current behavior and think it is a bug to import file.el at revision 9458. Note that the workaround for me is to use:

   $ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD

But it would be lot cleaner to have git-svn handling this properly I think.

Thanks, Pascal.

Pascal Obry a écrit :

I meant moved as /trunk/PROJ1 then /trunk/PROJ2... and so on.

Pascal.

Pascal Obry <pascal.obry@gmail.com> wrote:

Since r48468 was where /importfromcvs/trunk got renamed into /trunk/PROJ (from your previous message http://mid.gmane.org/4764FE2C.1010103@obry.net)

/importfromcvs/trunk exists at r45775, but /trunk/PROJ does not; and git-svn at least follows that (which is what I suppose everybody wants).

However...

Did /importfromcvs/trunk exist all the way between r9458 and r48468? Or was that directory replaced entirely by something else along the way?

git-svn may be following copy history too aggressively, in this case.

On the other hand, this was somewhat intended because it could also be a way to track merges as "moving" tags[1].

Does --no-follow-parent work in your case? Or does it go too far in stopping at r48468 (probably).

[1] - I follow a project that has a RELEASE branch that is occasionally deleted and replaced with the contents of trunk. git-svn will actually import this as a merge commit with two parents:

  1. trunk (obviously)
  2. the previous RELEASE, which was deleted

This allows old (but deleted) history to still be visible, which is what *I* always want. However, it could cause undesired behavior in your case...

Note that running 'svn log <URL of #2 case>' will NOT show what git-svn log will show for two; and I think it's nice that git-svn will track history that is harder to find with SVN

(which would require svn log -v <URL of #2 case>@<rev>).

Maybe another switch should be added (--merge-foster-parent?)

Eric,

Right.

It was replaced along the way. This very same tree /importfromcvs/trunk was used to import completely unrelated projects. Then moved, so it did not exist all the way.

In my case the previous version on this tree was 45546. There is nothing in between 45546 and 45775 for example. So looking at any revision in between return an error:

$ svn log -v svn+ssh://myserver/importfromcvs/trunk@45760 svn: File not found: revision 45760, path '/importfromcvs/trunk'

Looks like it is the case. Hence the reported errors:

W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path '/trunk/PROJ'

and

W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 101, path
'/importfromcvs/trunk'

For sure there was no revision 101 on /importfromcvs/trunk:

$ svn log -v svn+ssh://myserver/importfromcvs/trunk@101 svn: File not found: revision 101, path '/importfromcvs/trunk'

No it works on my case. That's what I'm using to import the directory in two steps. I just want to go to the bottom of this to see if we can somehow improve git-svn.

I'm not sure to understand what you are proposing here. To look only at parents that are directly "related" to the current branch ?

Thanks, Pascal.

Eric,

Yes part of it but before the creation of the /importfromcvs/trunk/ that was moved later as /trunk/PROJ.

In /importfromcvs/trunk/ there was many projects imported. One per one, each time moving it into /trunk/PROJ.

If I look at history of /trunk/PROJ:

   $ svn log svn+ssh://myserver/trunk/PROJ

The last revision is 45775, so I think git-svn should not look past this revision. So I'm very surprised by the current behavior and think it is a bug to import file.el at revision 9458. Note that the workaround for me is to use:

   $ git svn clone svn+ssh://myserver/trunk/PROJ --revision=45775:HEAD

But it would be lot cleaner to have git-svn handling this properly I think.

Thanks, Pascal.