Pascal Obry <pascal.obry@xxxxxxxxx> 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@xxxxxxxx) /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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
