threads / discuss / 18050

git-svn woes

Subject: git-svn woes

## tl;dr

7 messages between Feb 27, 2009 and Feb 28, 2009.

replies: 6people: 5as markdown or json

Nicolas Pitre· Feb 27, 2009, 20:37 UTC · lore

OK... I cannot pretend to be a newbie with git. However it's the first time I try git-svn and it looks like a couple basic things aren't right.

I initially cloned svn://svn.berlios.de/openocd using "git svn clone -s". So far so good. Now I'm attempting to update using "git svn fetch" but the operation always fails with the following error:

|branch_from: /openocd/branches => /openocd/branches/xscale
|Found possible branch point: 
|svn://svn.berlios.de/openocd/openocd/branches/xscale => 
|svn://svn.berlios.de/openocd/branches/xscale, 1231
|Initializing parent: xscale@1231
|Found branch parent: (xscale) 657522f3f2d1ab8b679fd5b45ce4e9ca1974af18
|Following parent with do_switch
|Scanning for empty symlinks, this may take a while if you have many empty files
|You may disable this with `git config svn.brokenSymlinkWorkaround false'.
|This may be done in a different terminal without restarting git svn
|Malformed network data: Malformed network data at /home/nico/libexec/git-core/git-svn line 3333

Thing is... the repository never gets updated and by far. According to "git svn info", the fetched revision is 1232, while a separate repository using native svn claims to be at revision 1383.

Furthermore, the "git svn info" command produces yet more errors, such as:

|Use of uninitialized value $lc_author in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 964.
|Use of uninitialized value $lc_rev in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 965.
|Use of uninitialized value $t in gmtime at /home/nico/libexec/git-core/git-svn line 4743.
|Use of uninitialized value $t in numeric comparison (<=>) at /home/nico/libexec/git-core/git-svn line 4744.
|Use of uninitialized value $t in subtraction (-) at /home/nico/libexec/git-core/git-svn line 4745.
|Use of uninitialized value $t in localtime at /home/nico/libexec/git-core/git-svn line 4746.

This is with git from current "next". I cannot spend time to try fixing the issue myself (especially as I'm not familiar at all with the inner workings of svn), so my only option at the moment is to give up on git-svn altogether. :-(

Nicolas
Deskin Miller· Feb 27, 2009, 20:53 UTC · re: Nicolas Pitre · lore

Re: git-svn woes

On Fri, Feb 27, 2009 at 15:37, Nicolas Pitre <nico@cam.org> wrote:
Show 19 quoted lines
>
> OK... I cannot pretend to be a newbie with git.  However it's the first
> time I try git-svn and it looks like a couple basic things aren't right.
>
> I initially cloned svn://svn.berlios.de/openocd using "git svn clone -s".
> So far so good.  Now I'm attempting to update using "git svn fetch" but
> the operation always fails with the following error:
>
> |branch_from: /openocd/branches => /openocd/branches/xscale
> |Found possible branch point:
> |svn://svn.berlios.de/openocd/openocd/branches/xscale =>
> |svn://svn.berlios.de/openocd/branches/xscale, 1231
> |Initializing parent: xscale@1231
> |Found branch parent: (xscale) 657522f3f2d1ab8b679fd5b45ce4e9ca1974af18
> |Following parent with do_switch
> |Scanning for empty symlinks, this may take a while if you have many empty files
> |You may disable this with `git config svn.brokenSymlinkWorkaround false'.
> |This may be done in a different terminal without restarting git svn
> |Malformed network data: Malformed network data at /home/nico/libexec/git-core/git-svn line 3333

I experience the same error as you do with 1.6.2-rc2. This error is occurring in the new broken-symlink-workaround code. I'm not sure what is going on and don't have time to examine it closely, but the function where the error occurs doesn't run if the config svn.brokenSymlinkWorkaround option is set false; doing so makes the fetch continue for me.

Any ideas, Eric?
Show 18 quoted lines
> Thing is... the repository never gets updated and by far.  According to
> "git svn info", the fetched revision is 1232, while a separate
> repository using native svn claims to be at revision 1383.
>
> Furthermore, the "git svn info" command produces yet more errors, such
> as:
>
> |Use of uninitialized value $lc_author in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 964.
> |Use of uninitialized value $lc_rev in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 965.
> |Use of uninitialized value $t in gmtime at /home/nico/libexec/git-core/git-svn line 4743.
> |Use of uninitialized value $t in numeric comparison (<=>) at /home/nico/libexec/git-core/git-svn line 4744.
> |Use of uninitialized value $t in subtraction (-) at /home/nico/libexec/git-core/git-svn line 4745.
> |Use of uninitialized value $t in localtime at /home/nico/libexec/git-core/git-svn line 4746.
>
> This is with git from current "next". I cannot spend time to try fixing
> the issue myself (especially as I'm not familiar at all with the inner
> workings of svn), so my only option at the moment is to give up on
> git-svn altogether.  :-(
Oh, don't give up quite yet :)
Deskin Miler
Eric Wong· Feb 28, 2009, 03:31 UTC · re: Deskin Miller · lore

Re: git-svn woes

Deskin Miller <deskinm@gmail.com> wrote:
Show 29 quoted lines
> On Fri, Feb 27, 2009 at 15:37, Nicolas Pitre <nico@cam.org> wrote:
> >
> > OK... I cannot pretend to be a newbie with git.  However it's the first
> > time I try git-svn and it looks like a couple basic things aren't right.
> >
> > I initially cloned svn://svn.berlios.de/openocd using "git svn clone -s".
> > So far so good.  Now I'm attempting to update using "git svn fetch" but
> > the operation always fails with the following error:
> >
> > |branch_from: /openocd/branches => /openocd/branches/xscale
> > |Found possible branch point:
> > |svn://svn.berlios.de/openocd/openocd/branches/xscale =>
> > |svn://svn.berlios.de/openocd/branches/xscale, 1231
> > |Initializing parent: xscale@1231
> > |Found branch parent: (xscale) 657522f3f2d1ab8b679fd5b45ce4e9ca1974af18
> > |Following parent with do_switch
> > |Scanning for empty symlinks, this may take a while if you have many empty files
> > |You may disable this with `git config svn.brokenSymlinkWorkaround false'.
> > |This may be done in a different terminal without restarting git svn
> > |Malformed network data: Malformed network data at /home/nico/libexec/git-core/git-svn line 3333
> 
> I experience the same error as you do with 1.6.2-rc2.  This error is
> occurring in the new broken-symlink-workaround code.  I'm not sure
> what is going on and don't have time to examine it closely, but the
> function where the error occurs doesn't run if the config
> svn.brokenSymlinkWorkaround option is set false; doing so makes the
> fetch continue for me.
> 
> Any ideas, Eric?

I've been poking around at this for a bit, I am pretty confused by this, too. It's been a rough week, so I could be missing something obvious...

Junio: since 1.6.2 might be out the door before we have time to resolve
this, I'm leaning towards disabling the broken-symlink-workaround by
default for the release. It seems far more people are negatively
affected by the attempted fix around this rare problem than helped.
Show 22 quoted lines
> > Thing is... the repository never gets updated and by far.  According to
> > "git svn info", the fetched revision is 1232, while a separate
> > repository using native svn claims to be at revision 1383.
> >
> > Furthermore, the "git svn info" command produces yet more errors, such
> > as:
> >
> > |Use of uninitialized value $lc_author in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 964.
> > |Use of uninitialized value $lc_rev in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 965.
> > |Use of uninitialized value $t in gmtime at /home/nico/libexec/git-core/git-svn line 4743.
> > |Use of uninitialized value $t in numeric comparison (<=>) at /home/nico/libexec/git-core/git-svn line 4744.
> > |Use of uninitialized value $t in subtraction (-) at /home/nico/libexec/git-core/git-svn line 4745.
> > |Use of uninitialized value $t in localtime at /home/nico/libexec/git-core/git-svn line 4746.
> >
> > This is with git from current "next". I cannot spend time to try fixing
> > the issue myself (especially as I'm not familiar at all with the inner
> > workings of svn), so my only option at the moment is to give up on
> > git-svn altogether.  :-(
> 
> Oh, don't give up quite yet :)
> 
> Deskin Miler
-- 
Eric Wong
Junio C Hamano· Feb 28, 2009, 03:41 UTC · re: Eric Wong · lore

Re: git-svn woes

Eric Wong <normalperson@yhbt.net> writes:
Show 8 quoted lines
> I've been poking around at this for a bit, I am pretty confused
> by this, too.  It's been a rough week, so I could be missing
> something obvious...
>
> Junio: since 1.6.2 might be out the door before we have time to resolve
> this, I'm leaning towards disabling the broken-symlink-workaround by
> default for the release. It seems far more people are negatively
> affected by the attempted fix around this rare problem than helped.

I agree that unfortunately is the message I am getting from the list ever since the feature was introduced.

Eric Wong· Feb 28, 2009, 04:09 UTC · re: Junio C Hamano · lore

Re: git-svn woes

Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> Eric Wong <normalperson@yhbt.net> writes:
> 
> > I've been poking around at this for a bit, I am pretty confused
> > by this, too.  It's been a rough week, so I could be missing
> > something obvious...
> >
> > Junio: since 1.6.2 might be out the door before we have time to resolve
> > this, I'm leaning towards disabling the broken-symlink-workaround by
> > default for the release. It seems far more people are negatively
> > affected by the attempted fix around this rare problem than helped.
> 
> I agree that unfortunately is the message I am getting from the list ever
> since the feature was introduced.
OK, here goes:
>From 0985d9190d0f85b1285de4f23f87bdfd9e0c0fff Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Fri, 27 Feb 2009 19:40:16 -0800
Subject: [PATCH] git-svn: disable broken symlink workaround by default

Even though this will break things for some extremely rare repositories used by broken Windows clients, it's probably not worth enabling this by default as it has negatively affected many more users than it has helped from what we've seen so far.

The extremely rare repositories that have broken symlinks in them will be silently corrupted in import; but users can still reenable this option and restart the import.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
 git-svn.perl                     |    2 +-
 t/t9131-git-svn-empty-symlink.sh |   10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 55702d0..959eb52 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3297,7 +3297,7 @@ sub new {
 sub _mark_empty_symlinks {
 	my ($git_svn, $switch_path) = @_;
 	my $bool = Git::config_bool('svn.brokenSymlinkWorkaround');
-	return {} if (defined($bool) && ! $bool);
+	return {} if (!defined($bool)) || (defined($bool) && ! $bool);
 
 	my %ret;
 	my ($rev, $cmt) = $git_svn->last_rev_commit;
diff --git a/t/t9131-git-svn-empty-symlink.sh b/t/t9131-git-svn-empty-symlink.sh
index 20529a8..8f35e29 100755
--- a/t/t9131-git-svn-empty-symlink.sh
+++ b/t/t9131-git-svn-empty-symlink.sh
@@ -83,6 +83,8 @@ EOF
 '
 
 test_expect_success 'clone using git svn' 'git svn clone -r1 "$svnrepo" x'
+test_expect_success 'enable broken symlink workaround' \
+  '(cd x && git config svn.brokenSymlinkWorkaround true)'
 test_expect_success '"bar" is an empty file' 'test -f x/bar && ! test -s x/bar'
 test_expect_success 'get "bar" => symlink fix from svn' \
 		'(cd x && git svn rebase)'
@@ -97,4 +99,12 @@ test_expect_success 'get "bar" => symlink fix from svn' \
 		'(cd y && git svn rebase)'
 test_expect_success '"bar" does not become a symlink' '! test -L y/bar'
 
+# svn.brokenSymlinkWorkaround is unset
+test_expect_success 'clone using git svn' 'git svn clone -r1 "$svnrepo" z'
+test_expect_success '"bar" is an empty file' 'test -f z/bar && ! test -s z/bar'
+test_expect_success 'get "bar" => symlink fix from svn' \
+		'(cd z && git svn rebase)'
+test_expect_success '"bar" does not become a symlink' '! test -L z/bar'
+
+
 test_done

-- 
1.6.2.rc2.5.g0c347
Junio C Hamano· Feb 28, 2009, 05:54 UTC · re: Eric Wong · lore

Re: git-svn woes

Eric Wong <normalperson@yhbt.net> writes:
Show 16 quoted lines
> Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Wong <normalperson@yhbt.net> writes:
>> 
>> > I've been poking around at this for a bit, I am pretty confused
>> > by this, too.  It's been a rough week, so I could be missing
>> > something obvious...
>> >
>> > Junio: since 1.6.2 might be out the door before we have time to resolve
>> > this, I'm leaning towards disabling the broken-symlink-workaround by
>> > default for the release. It seems far more people are negatively
>> > affected by the attempted fix around this rare problem than helped.
>> 
>> I agree that unfortunately is the message I am getting from the list ever
>> since the feature was introduced.
>
> OK, here goes:
Thanks; applied together with Ben Walton's "format_svn_date" fix.
Ben Walton· Feb 27, 2009, 21:02 UTC · re: Nicolas Pitre · lore

Re: git-svn woes

Excerpts from Nicolas Pitre's message of Fri Feb 27 15:37:16 -0500 2009:
Show 6 quoted lines
> |Use of uninitialized value $lc_author in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 964.
> |Use of uninitialized value $lc_rev in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 965.
> |Use of uninitialized value $t in gmtime at /home/nico/libexec/git-core/git-svn line 4743.
> |Use of uninitialized value $t in numeric comparison (<=>) at /home/nico/libexec/git-core/git-svn line 4744.
> |Use of uninitialized value $t in subtraction (-) at /home/nico/libexec/git-core/git-svn line 4745.
> |Use of uninitialized value $t in localtime at /home/nico/libexec/git-core/git-svn line 4746.

All of the $t references are due to the patch I kicked in a few days back. $t is set to the first function argument, which in this case was passed as a null reference. Should $t default to time() in this circumstance? That would match the previous behaviour when localtime(shift) was used, although it may mask errors like this...?

If so, I'll submit a small patch for that asap.

As for why it's getting a null reference if it shouldn't be, I'll leave that for the people that know the svn part of this.

HTH. -Ben

-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.

← back to recent threads