Re: Problem with git-svn

[Eric Wong <normalperson@yhbt.net>]

Pascal Obry <pascal.obry@gmail.com> wrote:
> Eric,
> 
> > 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.
> 
> Yes part of it but before the creation of the /importfromcvs/trunk/ that
> was moved later as /trunk/PROJ.
> 
> < I meant moved as /trunk/PROJ1 then /trunk/PROJ2... and so on.
>
> 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:

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].

>    $ 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.

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 Wong