Bug#426407: closed by Gerrit Pape [EMAIL PROTECTED] (reply to [EMAIL PROTECTED]) (Re: Bug#426407: git-svn: --follow-parent does not follow moves of parent directories)
Hi, thanks for your reply. I have a few final comments on this matter. I think that you and SVN have the correct idea, that when you run 'svn log file:///tmp/test/svn_repo/trunk', then you are asking for the history of the trunk sub-directory, which didn't exist (in my previous example) more than 2 revisions ago. I think it comes down to me trying to do a few complicated things during my import: 1) Track only the history of the 'trunk' directory (I don't want directories called tags and branches in a git repo) - ie something like this: svn log file:///tmp/test/svn_repo/trunk/* 2) Track the entire history of files, even before they were moved to 'trunk' - Hard to do if you only get the history of a single directory 3) There wasn't always a tidy 'trunk'/'branches'/'tags' sub-division - Which rules out using git-svnimport, which needs the above layout. 4) Sometimes the entire project sub-directory in svn changed (eg: projects/old_project renamed to projects/new_project somewhere in the past) - This rules out importing the entire project directory (including trunk,branches,tags) with git-svn, since it (probably?) won't retrieve history from projects/old_project. I agree that the above requirements are very hard for an importer to follow sanely in all cases :-) So, in cases like the above I will continue to manually fix up history with a series of 'git-svn init' and 'git-svn fetch' commands (with revision ranges and svn paths) during my initial import. Perhaps I can forward a HOWTO I put together for doing the above? Then users can refer to it when they have 'svn log'-unfriendly histories like mine, but want to get the entire (relevant) history into git regardless. Regards, David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426407: git-svn: --follow-parent does not follow moves of parent directories
On Tue, Jun 19, 2007 at 09:21:56AM +0200, David Purdy wrote: On Mon, May 28, 2007 at 04:43:04PM +0200, David Purdy wrote: 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. Replying late because this mail was caught by my spam filters. Sadly I'm still having this error. My current versions: git-core: 1:1.5.4.1-1 git-svn: 1:1.5.4.1-1 I ran 'apt-get dist-upgrade' today (against Debian/Testing) so all my other packages should be recent versions. Here are some steps you can follow to reproduce my problem: # Create SVN history mkdir /tmp/test svnadmin create /tmp/test/svn_repo mkdir /tmp/test/svn_checkout cd /tmp/test/svn_checkout svn co file:///tmp/test/svn_repo cd svn_repo touch 1 2 3 svn add 1 2 3 svn ci -m New files ls 1; ls 2; ls 3 svn ci -m 'Some random update' mkdir trunk svn add trunk svn mv 1 trunk/ svn mv 2 trunk/ svn mv 3 trunk/ svn ci -m 'Moved files to trunk' cd trunk/ ls -l 1; ls -l 2; ls -l 3 svn ci -m 'Another random update' # Create git-svn checkout mkdir /tmp/test/svn-git_repo cd /tmp/test/svn-git_repo git-svn init file:///tmp/test/svn_repo/trunk git-svn fetch # Check the git log: git log In my case I only see the last 2 git revisions (the latest 2, Another random update and Moved files to trunk), rather than the 4 which exist in the SVN repo. I hope this info helps. David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426407: git-svn: --follow-parent does not follow moves of parent directories
On Tue, Jun 19, 2007 at 09:21:56AM +0200, David Purdy wrote: On Mon, May 28, 2007 at 04:43:04PM +0200, David Purdy wrote: 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 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. Hi David, git 1.5.4 is available in unstable now, again there's been work done on git-svn. May I ask you to check again with 1.5.4 whether the problem you experienced still exists? Thanks, Gerrit. 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]
Bug#426407: git-svn: --follow-parent does not follow moves of parent directories
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]
Bug#426407: git-svn: --follow-parent does not follow moves of parent directories
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426407: git-svn: --follow-parent does not follow moves of parent directories
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. eg: SVN server has these files in r1: /a/b/c/1.txt /a/b/c/2.txt /a/b/c/3.txt And in r2 /a/b/ was moved to /x: A /x D /a/b and in r3 some changed text files: M /x/c/1.txt M /x/c/2.txt But if you do this on your dev box: git-svn init svn://SERVER/myproject/x/c git-svn fetch --follow-parent Then git-svn will not pickup that /x/c was moved from /a/b/c, and you only get r3 in your git repo. ie, your git-svn history looks like this: r3: (Commit comment for r3) A 1.txt A 2.txt A 3.txt Instead of: r1: (Commit comment for r1) A 1.txt A 2.txt A 3.txt r2: (Commit comment for r2) - No files were changed here r3: (Commit comment for r3) M 1.txt M 2.txt My work-around to get complete history: git-svn init svn://SERVER/myproject/a/b/c git-svn fetch -r1 git-svn init svn://SERVER/myproject/x/c git-svn fetch -r2:HEAD echo Last commit ID in output above ./.git/refs/heads/master Explanation: The second 'fetch' fetches the listed revisions connects commit r1 to r2, but it doesn't update your master 'head commit' file. I tried the instructions under Advanced Example: Tracking a Reorganized Repository, but they didn't work for me. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages git-svn depends on: ii git-core1:1.4.4.4-2 content addressable filesystem ii libsvn-perl [libsvn-core-pe 1.4.2dfsg1-2 Perl bindings for Subversion ii libwww-perl 5.805-1 WWW client/server library for Perl Versions of packages git-svn recommends: ii git-doc 1:1.4.4.4-2 content addressable filesystem (do -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
