git-svn woes

git-svn woes

[Nicolas Pitre]

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

Re: git-svn woes

[Deskin Miller]

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?

> 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

Re: git-svn woes

[Ben Walton]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

Excerpts from Nicolas Pitre's message of Fri Feb 27 15:37:16 -0500 2009:
> |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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git-svn woes

[Eric Wong]

Deskin Miller <deskinm@gmail.com> wrote:
> 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.

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

Re: git-svn woes

[Junio C Hamano]

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.

Re: git-svn woes

[Eric Wong]

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:

>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

Re: git-svn woes

[Junio C Hamano]

Eric Wong <normalperson@yhbt.net> writes:

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