> On Mon, May 28, 2007 at 04:43:04PM +0200, David Purdy wrote: > > Package: git-svn > > Version: 1:1.4.4.4-2 > > Severity: normal > > > > git-svn fetch --follow-parent does not work correctly for cases where a > > parent of the directory you're tracking is moved. > > Hi David, can you please check with git-svn version 1.5.2.1 whether this > problem still exists? A lot of work has been done on git-svn since > 1.4.4.4. > > Thanks, Gerrit.
Hi Gerrit. Thanks for your reply. I was using 1.4.4.4 because that's the one in testing. git-svn 1.5.2.1 from unstable works much better. In most cases it is detecting moves of parent directories. There is still one case it is not detecting. Example SVN history: r1: Initial import A /A/B/1.txt A /A/B/2.txt A /A/B/3.txt r2: Some changes M /A/B/1.txt M /A/B/2.txt M /A/B/3.txt r3: Moved files to a trunk dirctory: M /A/B D /A/B/1.txt D /A/B/2.txt D /A/B/3.txt A /A/B/trunk/1.txt (from /A/B/1.txt:2) A /A/B/trunk/2.txt (from /A/B/2.txt:2) A /A/B/trunk/3.txt (from /A/B/3.txt:3) r4: Made more changes: M /A/B/trunk/1.txt M /A/B/trunk/2.txt M /A/B/trunk/3.txt If you run: git-svn import svn:<server>/A/B/trunk/ git-svn fetch Then 'git-svn fetch' detects r3 as the first revision, rather than r1. This is a corner case. eg, what should git-svn do when the parent directory /A/B (r2) had a lot of other files and sub-dirs in it besides trunk? I think that in this case git-svn should emit a warning, and then behave as though all those other files and sub-dirs were deleted going from r2 to r3. Then it should be fine to change our 'base' directory in the repo from "/A/B/trunk" to "/A/B" (going backwards from r3 to r2). David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
