Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-03-23 Thread Eric Wong 
Junio C Hamano gits...@pobox.com wrote:
 Eric Wong normalper...@yhbt.net writes:
  Kyle J. McKay mack...@gmail.com wrote:
  The updated patch with the additional fix is below.
 
  Thanks, signed-off and pushed to master on git://bogomips.org/git-svn
  I've dropped my destroy all tempfiles... patch.
 
 I think I missed this exchange.  I see these two patches:
 
 e0b4cad Git::SVN::*: avoid premature FileHandle closure
 ce1b57b git-svn: fix localtime=true on non-glibc environments
 
 on the 'master' branch of your git://git.bogomips.org/git-svn.git/
 repository.  Is this a good time to pull from you, and should I
 expect more during this cycle (I am guessing that the answers would
 be yes and no, but just to make sure...)?

Correct, it's a good time to pull and I don't expect to have more time
to work on new features (lazy load) for a bit.  I was under the
impression you already pulled:

http://mid.gmane.org/xmqq61aol44q@gitster.dls.corp.google.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-03-23 Thread Junio C Hamano 
Eric Wong normalper...@yhbt.net writes:

 Correct, it's a good time to pull and I don't expect to have more time
 to work on new features (lazy load) for a bit.  I was under the
 impression you already pulled:

 http://mid.gmane.org/xmqq61aol44q@gitster.dls.corp.google.com

Indeed I did.  I was fooled by my own rebase X-.

Thanks, then I am fully up to date with you.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-03-23 Thread Junio C Hamano 
Eric Wong normalper...@yhbt.net writes:

 Kyle J. McKay mack...@gmail.com wrote:
 The updated patch with the additional fix is below.

 Thanks, signed-off and pushed to master on git://bogomips.org/git-svn
 I've dropped my destroy all tempfiles... patch.

I think I missed this exchange.  I see these two patches:

e0b4cad Git::SVN::*: avoid premature FileHandle closure
ce1b57b git-svn: fix localtime=true on non-glibc environments

on the 'master' branch of your git://git.bogomips.org/git-svn.git/
repository.  Is this a good time to pull from you, and should I
expect more during this cycle (I am guessing that the answers would
be yes and no, but just to make sure...)?

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-02-26 Thread Kyle J. McKay 
On Feb 26, 2015, at 01:09, Nico Schl=F6mer wrote:
 All,

 I applied Kyle's latest patch

 diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
 index 622535e2..96888228 100644
 --- a/perl/Git/SVN/Ra.pm
 +++ b/perl/Git/SVN/Ra.pm
 @@ -391,6 +391,7 @@ sub longest_common_path {
 sub gs_fetch_loop_common {
my ($self, $base, $head, $gsv, $globs) =3D @_;
return if ($base  $head);
 +   $::_repository-_open_cat_blob_if_needed;
my $gpool =3D SVN::Pool-new_default;
my $ra_url =3D $self-url;
my $reload_ra =3D sub {

 alone and this fixes the bug for me. Thanks a lot, Kyle!

The updated patch with the additional fix is below.

There are two symptoms it addresses:

1) the 'Git_svn_hash_... bad file descriptor' failure

2) the 'out pipe went bad' failure

While (1) could probably also be addressed by Eric's alternate
destroy all tempfiles when reloading RA patch, that would require re-
opening all the temp files every 100 revisions (or whatever the log
window size is changed to).

I noticed that with the default log window size of 100 revisions, each
time the connection was reset at the 100-revision boundary (to reduce
the overall memory usage) it seemed to take approx. 3 seconds to start
up again processing revisions on that gmsh repository.  If you're
cloning 3 revisions, that adds 15 minutes to the total clone time
already.  Admittedly opening new temp files will be a lot faster and
hardly noticeable, but doing that 300 times over the course of 3
revisions will probably add at least a little extra delay and since
blowing away all the temp files does not seem to be necessary, why
incur the extra delay?

Also the destroy all tempfiles when reloading RA patch isn't going
to fix the cat_blob 'out pipe went bad' problem since that has nothing
to do with the temp files so another change will still be required for
that.

-Kyle

-- 8 --
Subject: [PATCH v2] Git::SVN::*: avoid premature FileHandle closure

Since b19138b (git-svn: Make it incrementally faster by minimizing temp
files, v1.6.0), git-svn has been using the Git.pm temp_acquire and
temp_release mechanism to avoid unnecessary temp file churn and provide
a speed boost.

However, that change introduced a call to temp_acquire inside the
Git::SVN::Fetcher::close_file function for an 'svn_hash' temp file.
Because an SVN::Pool is active at the time this function is called, if
the Git::temp_acquire function ends up actually creating a new
FileHandle for the temp file (which it will the first time it's called
with the name 'svn_hash') that FileHandle will end up in the SVN::Pool
and should that pool have SVN::Pool::clear called on it that FileHandle
will be closed out from under Git::temp_acquire.

Since the only call site to Git::temp_acquire with the name 'svn_hash'
is inside the close_file function, if an 'svn_hash' temp file is ever
created its FileHandle is guaranteed to be created in the active
SVN::Pool.

This has not been a problem in the past because the SVN::Pool was not
being cleared.  However, since dfa72fdb (git-svn: reload RA every
log-window-size, v2.2.0) the pool has been getting cleared periodically
at which point the FileHandle for the 'svn_hash' temp file gets closed.
Any subsequent calls to Git::temp_acquire for 'svn_hash', however,
succeed without creating/opening a new temporary file since it still has
the now invalid FileHandle in its cache.  Callers that then attempt to
use that FileHandle fail with an error.

We avoid this problem by making sure the 'svn_hash' temp file is created
in the same place the 'svn_delta_...' and 'git_blob_...' temp files are
(and then temp_release'd) so that it can be safely used inside the
close_file function without having its FileHandle end up in an SVN::Pool
that gets cleared.

Additionally the Git.pm cat_blob function creates a bidirectional pipe
FileHandle using the IPC::Open2::open2 function.  If that handle is
created too late, it also gets caught up in the SVN::Pool and incorrectly
closed by the SVN::Pool::clear call.  But this only seems to happen with
more recent versions of Perl and svn.

To avoid this problem we add an explicit call to _open_cat_blob_if_needed
before the first call to SVN::Pool-new_default to make sure the open2
handle does not end up in the SVN::Pool.

Signed-off-by: Kyle J. McKay mack...@gmail.com
---
 perl/Git/SVN/Fetcher.pm | 8 
 perl/Git/SVN/Ra.pm  | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index 10edb277..613055a3 100644
--- a/perl/Git/SVN/Fetcher.pm
+++ b/perl/Git/SVN/Fetcher.pm
@@ -322,6 +322,14 @@ sub apply_textdelta {
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '', $fh or croak $!;
my $base = $::_repository-temp_acquire(git_blob_${$}_$suffix);
+   # close_file may call temp_acquire on 'svn_hash', but because of the
+   # call chain, if the temp_acquire call from close_file ends up being the
+

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-02-26 Thread Nico Schlömer 
All,

I applied Kyle's latest patch

 diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
 index 622535e2..96888228 100644
 --- a/perl/Git/SVN/Ra.pm
 +++ b/perl/Git/SVN/Ra.pm
 @@ -391,6 +391,7 @@ sub longest_common_path {
 sub gs_fetch_loop_common {
 my ($self, $base, $head, $gsv, $globs) = @_;
 return if ($base  $head);
 +   $::_repository-_open_cat_blob_if_needed;
 my $gpool = SVN::Pool-new_default;
 my $ra_url = $self-url;
 my $reload_ra = sub {

alone and this fixes the bug for me. Thanks a lot, Kyle!

Cheers,
Nico

On Thu, Feb 26, 2015 at 12:37 AM, Nico Schlömer
nico.schloe...@gmail.com wrote:
 Kyle,

 you are absolutely correct, I used the wrong Git installation in my last
 email. With both your and Eric's patches applied, I'm getting
 ```
 [...]
 r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
 Unexpected result returned from git cat-file at
 /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 344.
 Failed to read object 619f9d1d857fb287d06a70c9dac6b8b534d0de6a at
 /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 345, GEN16 line
 757.

 error closing pipe: Bad file descriptor at
 /home/nschloe/libexec/git-core/git-svn line 0.
 error closing pipe: Bad file descriptor at
 /home/nschloe/libexec/git-core/git-svn line 0.
 ```
 where line 344 is
 ```
 $size = $::_repository-cat_blob($fb-{blob}, $base);
 ```
 Adding the line in `perl/Git/SVN/Ra.pm` as per your suggestion does not
 change this.

 Cheers,
 Nico


 On Wed, Feb 25, 2015 at 9:34 PM Kyle J. McKay mack...@gmail.com wrote:

 On Feb 25, 2015, at 07:07, Nico Schlömer wrote:

  Thanks Kyle for the patch! I applied it and ran
  ```
  git svn clone https://geuz.org/svn/gmsh/trunk
  ```
  Unfortunately, I'm still getting
  ```
  [...]
  r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
  error closing pipe: Bad file descriptor at /usr/share/perl5/Git/SVN/
  Fetcher.pm line 335.
  error closing pipe: Bad file descriptor at /usr/share/perl5/Git/SVN/
  Fetcher.pm line 335.
  out pipe went bad at /usr/share/perl5/Git.pm line 955.
  ```

 Are you certain you're running with the patch?  I ask because earlier
 you sent this:

 On Jan 31, 2015, at 04:51, Nico Schlömer wrote:

  I tried the patch and I still get
  ```
  [...]
  r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
  Unexpected result returned from git cat-file at
  /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 335.
  Failed to read object 619f9d1d857fb287d06a70c9dac6b8b534d0de6a at
  /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 336, GEN16
  line 757.
 
  error closing pipe: Bad file descriptor at
  /home/nschloe/libexec/git-core/git-svn line 0.
  error closing pipe: Bad file descriptor at
  /home/nschloe/libexec/git-core/git-svn line 0.
  ```
  when
  ```
  git svn clone https://geuz.org/svn/gmsh/trunk
  ```

 And as the patch below applies to Fetcher.pm at line 322 and inserts 8
 lines, I do not see how you could be getting the same error message at
 line 335 if the patch was present.  Even if you manually applied it by
 only inserting the two lines of code, the line numbers would be at
 least 337, not 335 as reported above.  I also notice the path to
 Fetcher.pm is different from your earlier report.

 That said, the fact that it happens right after r100 (which is when
 SVN::Pool::clear is getting called) suggests there's another file
 handle getting caught up in the SVN::Pool somehow.  (When I try to
 clone gmsh, I got to r4885 before a server disconnection.)

 It could be as simple as the open2 call FileHandle result in later
 perl versions ends up in the SVN::Pool whereas in earlier Perl and/or
 svn versions it does not.

 What happens if you add this change on top of the Fetcher.pm change:

 diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
 index 622535e2..96888228 100644
 --- a/perl/Git/SVN/Ra.pm
 +++ b/perl/Git/SVN/Ra.pm
 @@ -391,6 +391,7 @@ sub longest_common_path {
   sub gs_fetch_loop_common {
 my ($self, $base, $head, $gsv, $globs) = @_;
 return if ($base  $head);
 +   $::_repository-_open_cat_blob_if_needed;
 my $gpool = SVN::Pool-new_default;
 my $ra_url = $self-url;
 my $reload_ra = sub {

 -Kyle

  Cheers,
  Nico
 
  On Wed, Feb 25, 2015 at 11:20 AM Kyle J. McKay mack...@gmail.com
  wrote:
  I believe I have been able to track down this problem and implement a
  fix.  Please report back if this patch fixes the problem for you.
 
  -Kyle
 
  -- 8 --
  Subject: [PATCH] Git::SVN::Fetcher: avoid premature 'svn_hash' temp
  file closure
 
  Since b19138b (git-svn: Make it incrementally faster by minimizing
  temp
  files, v1.6.0), git-svn has been using the Git.pm temp_acquire and
  temp_release mechanism to avoid unnecessary temp file churn and
  provide
  a speed boost.
 
  However, that change introduced a call to temp_acquire inside the
  Git::SVN::Fetcher::close_file function for an 'svn_hash'

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-02-25 Thread Eric Wong 
Nico Schlömer nico.schloe...@gmail.com wrote:
 Thanks Kyle for the patch! I applied it and ran
 ```
 git svn clone https://geuz.org/svn/gmsh/trunk
 ```
 Unfortunately, I'm still getting
 ```
 [...]
 r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
 error closing pipe: Bad file descriptor at
 /usr/share/perl5/Git/SVN/Fetcher.pm line 335.
 error closing pipe: Bad file descriptor at
 /usr/share/perl5/Git/SVN/Fetcher.pm line 335.
 out pipe went bad at /usr/share/perl5/Git.pm line 955.

Thanks for testing, is this with or without my other attempt at
fixing this problem applied?

http://mid.gmane.org/20150130002247.ga22...@dcvr.yhbt.net
(git-svn: destroy all tempfiles when reloading RA)

And can you try testing both with/without that patch if you
haven't already?  Thanks again.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-02-25 Thread Kyle J. McKay 

On Feb 25, 2015, at 07:07, Nico Schlömer wrote:


Thanks Kyle for the patch! I applied it and ran
```
git svn clone https://geuz.org/svn/gmsh/trunk
```
Unfortunately, I'm still getting
```
[...]
r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
error closing pipe: Bad file descriptor at /usr/share/perl5/Git/SVN/ 
Fetcher.pm line 335.
error closing pipe: Bad file descriptor at /usr/share/perl5/Git/SVN/ 
Fetcher.pm line 335.

out pipe went bad at /usr/share/perl5/Git.pm line 955.
```


Are you certain you're running with the patch?  I ask because earlier  
you sent this:


On Jan 31, 2015, at 04:51, Nico Schlömer wrote:


I tried the patch and I still get
```
[...]
r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
Unexpected result returned from git cat-file at
/home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 335.
Failed to read object 619f9d1d857fb287d06a70c9dac6b8b534d0de6a at
/home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 336, GEN16
line 757.

error closing pipe: Bad file descriptor at
/home/nschloe/libexec/git-core/git-svn line 0.
error closing pipe: Bad file descriptor at
/home/nschloe/libexec/git-core/git-svn line 0.
```
when
```
git svn clone https://geuz.org/svn/gmsh/trunk
```


And as the patch below applies to Fetcher.pm at line 322 and inserts 8  
lines, I do not see how you could be getting the same error message at  
line 335 if the patch was present.  Even if you manually applied it by  
only inserting the two lines of code, the line numbers would be at  
least 337, not 335 as reported above.  I also notice the path to  
Fetcher.pm is different from your earlier report.


That said, the fact that it happens right after r100 (which is when  
SVN::Pool::clear is getting called) suggests there's another file  
handle getting caught up in the SVN::Pool somehow.  (When I try to  
clone gmsh, I got to r4885 before a server disconnection.)


It could be as simple as the open2 call FileHandle result in later  
perl versions ends up in the SVN::Pool whereas in earlier Perl and/or  
svn versions it does not.


What happens if you add this change on top of the Fetcher.pm change:

diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 622535e2..96888228 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -391,6 +391,7 @@ sub longest_common_path {
 sub gs_fetch_loop_common {
my ($self, $base, $head, $gsv, $globs) = @_;
return if ($base  $head);
+   $::_repository-_open_cat_blob_if_needed;
my $gpool = SVN::Pool-new_default;
my $ra_url = $self-url;
my $reload_ra = sub {

-Kyle


Cheers,
Nico

On Wed, Feb 25, 2015 at 11:20 AM Kyle J. McKay mack...@gmail.com  
wrote:

I believe I have been able to track down this problem and implement a
fix.  Please report back if this patch fixes the problem for you.

-Kyle

-- 8 --
Subject: [PATCH] Git::SVN::Fetcher: avoid premature 'svn_hash' temp  
file closure


Since b19138b (git-svn: Make it incrementally faster by minimizing  
temp

files, v1.6.0), git-svn has been using the Git.pm temp_acquire and
temp_release mechanism to avoid unnecessary temp file churn and  
provide

a speed boost.

However, that change introduced a call to temp_acquire inside the
Git::SVN::Fetcher::close_file function for an 'svn_hash' temp file.
Because an SVN::Pool is active at the time this function is called, if
the Git::temp_acquire function ends up actually creating a new
FileHandle for the temp file (which it will the first time it's called
with the name 'svn_hash') that FileHandle will end up in the SVN::Pool
and should that pool have SVN::Pool::clear called on it that  
FileHandle

will be closed out from under Git::temp_acquire.

Since the only call site to Git::temp_acquire with the name 'svn_hash'
is inside the close_file function, if an 'svn_hash' temp file is ever
created its FileHandle is guaranteed to be created in the active
SVN::Pool.

This has not been a problem in the past because the SVN::Pool was not
being cleared.  However, since dfa72fdb (git-svn: reload RA every
log-window-size, v2.2.0) the pool has been getting cleared  
periodically
at which point the FileHandle for the 'svn_hash' temp file gets  
closed.

Any subsequent calls to Git::temp_acquire for 'svn_hash', however,
succeed without creating/opening a new temporary file since it still  
has

the now invalid FileHandle in its cache.  Callers that then attempt to
use that FileHandle fail with an error.

We avoid this problem by making sure the 'svn_hash' temp file is  
created
in the same place the 'svn_delta_...' and 'git_blob_...' temp files  
are

(and then temp_release'd) so that it can be safely used inside the
close_file function without having its FileHandle end up in an  
SVN::Pool

that gets cleared.

Signed-off-by: Kyle J. McKay mack...@gmail.com
---
 perl/Git/SVN/Fetcher.pm | 8 
 1 file changed, 8 insertions(+)

diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-02-25 Thread Kyle J. McKay 
I believe I have been able to track down this problem and implement a
fix.  Please report back if this patch fixes the problem for you.

-Kyle

-- 8 --
Subject: [PATCH] Git::SVN::Fetcher: avoid premature 'svn_hash' temp file closure

Since b19138b (git-svn: Make it incrementally faster by minimizing temp
files, v1.6.0), git-svn has been using the Git.pm temp_acquire and
temp_release mechanism to avoid unnecessary temp file churn and provide
a speed boost.

However, that change introduced a call to temp_acquire inside the
Git::SVN::Fetcher::close_file function for an 'svn_hash' temp file.
Because an SVN::Pool is active at the time this function is called, if
the Git::temp_acquire function ends up actually creating a new
FileHandle for the temp file (which it will the first time it's called
with the name 'svn_hash') that FileHandle will end up in the SVN::Pool
and should that pool have SVN::Pool::clear called on it that FileHandle
will be closed out from under Git::temp_acquire.

Since the only call site to Git::temp_acquire with the name 'svn_hash'
is inside the close_file function, if an 'svn_hash' temp file is ever
created its FileHandle is guaranteed to be created in the active
SVN::Pool.

This has not been a problem in the past because the SVN::Pool was not
being cleared.  However, since dfa72fdb (git-svn: reload RA every
log-window-size, v2.2.0) the pool has been getting cleared periodically
at which point the FileHandle for the 'svn_hash' temp file gets closed.
Any subsequent calls to Git::temp_acquire for 'svn_hash', however,
succeed without creating/opening a new temporary file since it still has
the now invalid FileHandle in its cache.  Callers that then attempt to
use that FileHandle fail with an error.

We avoid this problem by making sure the 'svn_hash' temp file is created
in the same place the 'svn_delta_...' and 'git_blob_...' temp files are
(and then temp_release'd) so that it can be safely used inside the
close_file function without having its FileHandle end up in an SVN::Pool
that gets cleared.

Signed-off-by: Kyle J. McKay mack...@gmail.com
---
 perl/Git/SVN/Fetcher.pm | 8 
 1 file changed, 8 insertions(+)

diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index 10edb277..613055a3 100644
--- a/perl/Git/SVN/Fetcher.pm
+++ b/perl/Git/SVN/Fetcher.pm
@@ -322,6 +322,14 @@ sub apply_textdelta {
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '', $fh or croak $!;
my $base = $::_repository-temp_acquire(git_blob_${$}_$suffix);
+   # close_file may call temp_acquire on 'svn_hash', but because of the
+   # call chain, if the temp_acquire call from close_file ends up being the
+   # call that first creates the 'svn_hash' temp file, then the FileHandle
+   # that's created as a result will end up in an SVN::Pool that we clear
+   # in SVN::Ra::gs_fetch_loop_common.  Avoid that by making sure the
+   # 'svn_hash' FileHandle is already created before close_file is called.
+   my $tmp_fh = $::_repository-temp_acquire('svn_hash');
+   $::_repository-temp_release($tmp_fh, 1);
 
if ($fb-{blob}) {
my ($base_is_link, $size);
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-02-16 Thread Eric Wong 
Nico Schlömer nico.schloe...@gmail.com wrote:
 I just double-checked and I can only produce this issue on one machine
 (tested on 3). Apparently, this is has nothing to do with Git itself
 then.
 
 Any ideas of what could be wrong?

What's different about that one machine?
e.g. SVN version, 64 vs 32-bit, Perl version, etc. could all be
factors (assuming identical git versions).

Also, any chance git was misinstalled somehow or your PATH was not
pointing to the correct git installation?

Thanks
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-02-16 Thread Nico Schlömer 
I just double-checked and I can only produce this issue on one machine
(tested on 3). Apparently, this is has nothing to do with Git itself
then.

Any ideas of what could be wrong?

Cheers,
Nico

On Thu, Feb 12, 2015 at 8:18 PM, Eric Wong normalper...@yhbt.net wrote:
 Valery Yundin yuval...@gmail.com wrote:
 On 31 January 2015 at 13:51, Nico Schlömer nico.schloe...@gmail.com wrote:
  I tried the patch and I still get
  ```
  [...]
  r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
  Unexpected result returned from git cat-file at
  /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 335.
  Failed to read object 619f9d1d857fb287d06a70c9dac6b8b534d0de6a at
  /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 336, GEN16
  line 757.
 
  error closing pipe: Bad file descriptor at
  /home/nschloe/libexec/git-core/git-svn line 0.
  error closing pipe: Bad file descriptor at
  /home/nschloe/libexec/git-core/git-svn line 0.
  ```
  when
  ```
  git svn clone https://geuz.org/svn/gmsh/trunk

 It seems that the same commit dfa72fdb96 is responsible for the error
 in git svn clone https://geuz.org/svn/gmsh/trunk;. But unlike in my
 case, the patch doesn't fix it.

 (top-posting corrected)

 Odd, I managed to clone that without issues, but I couldn't reproduce
 this problem with or without the tempfile clearing patch applied.

git svn clone --username gmsh https://geuz.org/svn/gmsh/trunk

 Anybody else?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-02-12 Thread Eric Wong 
Valery Yundin yuval...@gmail.com wrote:
 On 31 January 2015 at 13:51, Nico Schlömer nico.schloe...@gmail.com wrote:
  I tried the patch and I still get
  ```
  [...]
  r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
  Unexpected result returned from git cat-file at
  /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 335.
  Failed to read object 619f9d1d857fb287d06a70c9dac6b8b534d0de6a at
  /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 336, GEN16
  line 757.
 
  error closing pipe: Bad file descriptor at
  /home/nschloe/libexec/git-core/git-svn line 0.
  error closing pipe: Bad file descriptor at
  /home/nschloe/libexec/git-core/git-svn line 0.
  ```
  when
  ```
  git svn clone https://geuz.org/svn/gmsh/trunk
 
 It seems that the same commit dfa72fdb96 is responsible for the error
 in git svn clone https://geuz.org/svn/gmsh/trunk;. But unlike in my
 case, the patch doesn't fix it.

(top-posting corrected)

Odd, I managed to clone that without issues, but I couldn't reproduce
this problem with or without the tempfile clearing patch applied.

   git svn clone --username gmsh https://geuz.org/svn/gmsh/trunk

Anybody else?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-31 Thread Valery Yundin 
Hi,

It seems that the same commit dfa72fdb96 is responsible for the error
in git svn clone https://geuz.org/svn/gmsh/trunk;. But unlike in my
case, the patch doesn't fix it.

Cheers,
Valery


On 31 January 2015 at 13:51, Nico Schlömer nico.schloe...@gmail.com wrote:
 I tried the patch and I still get
 ```
 [...]
 r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
 Unexpected result returned from git cat-file at
 /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 335.
 Failed to read object 619f9d1d857fb287d06a70c9dac6b8b534d0de6a at
 /home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 336, GEN16
 line 757.

 error closing pipe: Bad file descriptor at
 /home/nschloe/libexec/git-core/git-svn line 0.
 error closing pipe: Bad file descriptor at
 /home/nschloe/libexec/git-core/git-svn line 0.
 ```
 when
 ```
 git svn clone https://geuz.org/svn/gmsh/trunk
 ```

 Cheers,
 Nico

 On Fri, Jan 30, 2015 at 2:30 AM, Eric Wong normalper...@yhbt.net wrote:
 Valery Yundin yuval...@gmail.com wrote:
 Hi,

 Your patch seems to fix the problem.
 I tried several times and I can svn clone the whole repository in one
 go without a crash.

 Thanks for the confirmation.  Cc-ing a few other folks who encountered
 this problem (and Bcc-ing some folks who emailed me privately).

 Can the rest of you give this patch a try on your respective platforms
 and confirm the fix?

 http://article.gmane.org/gmane.comp.version-control.git/263168/raw
 (also: http://mid.gmane.org/20150130002247.ga22...@dcvr.yhbt.net )

 Junio: assuming all goes well with testers, can you apply my patch
 to the appropriate maintenance tracks with Tested-by:s?
 I'm going offline in a few hours and don't think I'll be around
 much the next week or so.

 Thanks.

 Thanks,
 Valery

 On 30 January 2015 at 01:22, Eric Wong normalper...@yhbt.net wrote:
  Valery Yundin yuval...@gmail.com wrote:
  Hi,
 
  Here you go:
  dfa72fdb96befbd790f623bb2909a347176753c2 is the first bad commit
 
  Thank you.  Can you give the following patch a try?
  I have not been able to reproduce the problem on my end.
  If it doesn't work out, I might be out of ideas for a bit :/
  Increasing --log-window-size will help you run longer without
  the error, but that's not ideal as it can also eat memory.
 
  ---8--
  From: Eric Wong normalper...@yhbt.net
  Subject: [PATCH] git-svn: destroy all tempfiles when reloading RA
 
  This may fix the errors some users are seeing with:
  write .git/Git_svn_hash_XX: Bad file descriptor
 
  Thanks to Valery Yundin for helping bisect the problem introduced in
  commit dfa72fdb96befbd790f623bb2909a347176753c2
  (git-svn: reload RA every log-window-size)
 
  Cc: Valery Yundin yuval...@gmail.com
  Signed-off-by: Eric Wong normalper...@yhbt.net
  ---
   perl/Git.pm| 6 ++
   perl/Git/SVN/Ra.pm | 1 +
   2 files changed, 7 insertions(+)
 
  diff --git a/perl/Git.pm b/perl/Git.pm
  index b5905ee..698018e 100644
  --- a/perl/Git.pm
  +++ b/perl/Git.pm
  @@ -1347,6 +1347,12 @@ sub temp_path {
  $TEMP_FILES{$temp_fd}{fname};
   }
 
  +sub temp_reset_all {
  +   unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
  +   %TEMP_FILEMAP = ();
  +   %TEMP_FILES = ();
  +}
  +
   sub END {
  unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
   }
  diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
  index 622535e..878679d 100644
  --- a/perl/Git/SVN/Ra.pm
  +++ b/perl/Git/SVN/Ra.pm
  @@ -397,6 +397,7 @@ sub gs_fetch_loop_common {
  $_[0] = undef;
  $self = undef;
  $RA = undef;
  +   Git-temp_reset_all;
  $gpool-clear;
  $self = Git::SVN::Ra-new($ra_url);
  $ra_invalid = undef;
  --
  EW
 --
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-31 Thread Nico Schlömer 
I tried the patch and I still get
```
[...]
r100 = e2a9b5baa2cebb18591ecb04ff350410d52f36de (refs/remotes/git-svn)
Unexpected result returned from git cat-file at
/home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 335.
Failed to read object 619f9d1d857fb287d06a70c9dac6b8b534d0de6a at
/home/nschloe/share/perl/5.18.2/Git/SVN/Fetcher.pm line 336, GEN16
line 757.

error closing pipe: Bad file descriptor at
/home/nschloe/libexec/git-core/git-svn line 0.
error closing pipe: Bad file descriptor at
/home/nschloe/libexec/git-core/git-svn line 0.
```
when
```
git svn clone https://geuz.org/svn/gmsh/trunk
```

Cheers,
Nico

On Fri, Jan 30, 2015 at 2:30 AM, Eric Wong normalper...@yhbt.net wrote:
 Valery Yundin yuval...@gmail.com wrote:
 Hi,

 Your patch seems to fix the problem.
 I tried several times and I can svn clone the whole repository in one
 go without a crash.

 Thanks for the confirmation.  Cc-ing a few other folks who encountered
 this problem (and Bcc-ing some folks who emailed me privately).

 Can the rest of you give this patch a try on your respective platforms
 and confirm the fix?

 http://article.gmane.org/gmane.comp.version-control.git/263168/raw
 (also: http://mid.gmane.org/20150130002247.ga22...@dcvr.yhbt.net )

 Junio: assuming all goes well with testers, can you apply my patch
 to the appropriate maintenance tracks with Tested-by:s?
 I'm going offline in a few hours and don't think I'll be around
 much the next week or so.

 Thanks.

 Thanks,
 Valery

 On 30 January 2015 at 01:22, Eric Wong normalper...@yhbt.net wrote:
  Valery Yundin yuval...@gmail.com wrote:
  Hi,
 
  Here you go:
  dfa72fdb96befbd790f623bb2909a347176753c2 is the first bad commit
 
  Thank you.  Can you give the following patch a try?
  I have not been able to reproduce the problem on my end.
  If it doesn't work out, I might be out of ideas for a bit :/
  Increasing --log-window-size will help you run longer without
  the error, but that's not ideal as it can also eat memory.
 
  ---8--
  From: Eric Wong normalper...@yhbt.net
  Subject: [PATCH] git-svn: destroy all tempfiles when reloading RA
 
  This may fix the errors some users are seeing with:
  write .git/Git_svn_hash_XX: Bad file descriptor
 
  Thanks to Valery Yundin for helping bisect the problem introduced in
  commit dfa72fdb96befbd790f623bb2909a347176753c2
  (git-svn: reload RA every log-window-size)
 
  Cc: Valery Yundin yuval...@gmail.com
  Signed-off-by: Eric Wong normalper...@yhbt.net
  ---
   perl/Git.pm| 6 ++
   perl/Git/SVN/Ra.pm | 1 +
   2 files changed, 7 insertions(+)
 
  diff --git a/perl/Git.pm b/perl/Git.pm
  index b5905ee..698018e 100644
  --- a/perl/Git.pm
  +++ b/perl/Git.pm
  @@ -1347,6 +1347,12 @@ sub temp_path {
  $TEMP_FILES{$temp_fd}{fname};
   }
 
  +sub temp_reset_all {
  +   unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
  +   %TEMP_FILEMAP = ();
  +   %TEMP_FILES = ();
  +}
  +
   sub END {
  unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
   }
  diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
  index 622535e..878679d 100644
  --- a/perl/Git/SVN/Ra.pm
  +++ b/perl/Git/SVN/Ra.pm
  @@ -397,6 +397,7 @@ sub gs_fetch_loop_common {
  $_[0] = undef;
  $self = undef;
  $RA = undef;
  +   Git-temp_reset_all;
  $gpool-clear;
  $self = Git::SVN::Ra-new($ra_url);
  $ra_invalid = undef;
  --
  EW
 --
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-29 Thread Valery Yundin 
Hi,

Looks like there might be a bug in SVN import code. Here is the
command that fails

 git svn clone --username anonymous 
 svn://powhegbox.mib.infn.it/trunk/POWHEG-BOX

r217 = 2e6cdb1f4604b2256195590fa8275632971eac42 (refs/remotes/git-svn)
M   lhefread.f
M   Z_plus_jet/Born.f
M   Z_plus_jet/powheg.input
M   Z_plus_jet/init_processes.f
D   JJ/madgraph_3_flavours/born/nexternal.inc
write .git/Git_svn_hash_bl5Cj3: Bad file descriptor
 at /usr/lib/perl5/vendor_perl/5.20.1/x86_64-linux-thread-multi/SVN/Ra.pm
line 623.

Tested on:
git-svn version 2.3.0.rc2 (svn 1.8.11) - FAIL
git-svn version 2.2.2 (svn 1.8.10) - FAIL
git-svn version 1.8.4.5 (svn 1.8.11) - WORKS

PS unfortunately I don't have admin access to SVN repository

With best regards, Valery Yundin.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-29 Thread Eric Wong 
Valery Yundin yuval...@gmail.com wrote:
 Hi,
 
 Here you go:
 dfa72fdb96befbd790f623bb2909a347176753c2 is the first bad commit

Thank you.  Can you give the following patch a try?
I have not been able to reproduce the problem on my end.
If it doesn't work out, I might be out of ideas for a bit :/
Increasing --log-window-size will help you run longer without
the error, but that's not ideal as it can also eat memory.

---8--
From: Eric Wong normalper...@yhbt.net
Subject: [PATCH] git-svn: destroy all tempfiles when reloading RA

This may fix the errors some users are seeing with:
write .git/Git_svn_hash_XX: Bad file descriptor

Thanks to Valery Yundin for helping bisect the problem introduced in
commit dfa72fdb96befbd790f623bb2909a347176753c2
(git-svn: reload RA every log-window-size)

Cc: Valery Yundin yuval...@gmail.com
Signed-off-by: Eric Wong normalper...@yhbt.net
---
 perl/Git.pm| 6 ++
 perl/Git/SVN/Ra.pm | 1 +
 2 files changed, 7 insertions(+)

diff --git a/perl/Git.pm b/perl/Git.pm
index b5905ee..698018e 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1347,6 +1347,12 @@ sub temp_path {
$TEMP_FILES{$temp_fd}{fname};
 }
 
+sub temp_reset_all {
+   unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
+   %TEMP_FILEMAP = ();
+   %TEMP_FILES = ();
+}
+
 sub END {
unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
 }
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 622535e..878679d 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -397,6 +397,7 @@ sub gs_fetch_loop_common {
$_[0] = undef;
$self = undef;
$RA = undef;
+   Git-temp_reset_all;
$gpool-clear;
$self = Git::SVN::Ra-new($ra_url);
$ra_invalid = undef;
-- 
EW
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-29 Thread Valery Yundin 
Hi,

Your patch seems to fix the problem.
I tried several times and I can svn clone the whole repository in one
go without a crash.

Thanks,
Valery

On 30 January 2015 at 01:22, Eric Wong normalper...@yhbt.net wrote:
 Valery Yundin yuval...@gmail.com wrote:
 Hi,

 Here you go:
 dfa72fdb96befbd790f623bb2909a347176753c2 is the first bad commit

 Thank you.  Can you give the following patch a try?
 I have not been able to reproduce the problem on my end.
 If it doesn't work out, I might be out of ideas for a bit :/
 Increasing --log-window-size will help you run longer without
 the error, but that's not ideal as it can also eat memory.

 ---8--
 From: Eric Wong normalper...@yhbt.net
 Subject: [PATCH] git-svn: destroy all tempfiles when reloading RA

 This may fix the errors some users are seeing with:
 write .git/Git_svn_hash_XX: Bad file descriptor

 Thanks to Valery Yundin for helping bisect the problem introduced in
 commit dfa72fdb96befbd790f623bb2909a347176753c2
 (git-svn: reload RA every log-window-size)

 Cc: Valery Yundin yuval...@gmail.com
 Signed-off-by: Eric Wong normalper...@yhbt.net
 ---
  perl/Git.pm| 6 ++
  perl/Git/SVN/Ra.pm | 1 +
  2 files changed, 7 insertions(+)

 diff --git a/perl/Git.pm b/perl/Git.pm
 index b5905ee..698018e 100644
 --- a/perl/Git.pm
 +++ b/perl/Git.pm
 @@ -1347,6 +1347,12 @@ sub temp_path {
 $TEMP_FILES{$temp_fd}{fname};
  }

 +sub temp_reset_all {
 +   unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
 +   %TEMP_FILEMAP = ();
 +   %TEMP_FILES = ();
 +}
 +
  sub END {
 unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
  }
 diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
 index 622535e..878679d 100644
 --- a/perl/Git/SVN/Ra.pm
 +++ b/perl/Git/SVN/Ra.pm
 @@ -397,6 +397,7 @@ sub gs_fetch_loop_common {
 $_[0] = undef;
 $self = undef;
 $RA = undef;
 +   Git-temp_reset_all;
 $gpool-clear;
 $self = Git::SVN::Ra-new($ra_url);
 $ra_invalid = undef;
 --
 EW
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-29 Thread Eric Wong 
Valery Yundin yuval...@gmail.com wrote:
 Tested on:
 git-svn version 2.3.0.rc2 (svn 1.8.11) - FAIL
 git-svn version 2.2.2 (svn 1.8.10) - FAIL
 git-svn version 1.8.4.5 (svn 1.8.11) - WORKS

Thank you for that info.  Do you think you can bisect which
versions/revisions of git-svn introduced that failure for us?  I don't
have much time this part of the year for git-svn, but maybe it's related
to the performance work we did around fall 2014.

Thanks again.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-29 Thread Eric Wong 
Valery Yundin yuval...@gmail.com wrote:
 Hi,
 
 Your patch seems to fix the problem.
 I tried several times and I can svn clone the whole repository in one
 go without a crash.

Thanks for the confirmation.  Cc-ing a few other folks who encountered
this problem (and Bcc-ing some folks who emailed me privately).

Can the rest of you give this patch a try on your respective platforms
and confirm the fix?

http://article.gmane.org/gmane.comp.version-control.git/263168/raw
(also: http://mid.gmane.org/20150130002247.ga22...@dcvr.yhbt.net )

Junio: assuming all goes well with testers, can you apply my patch
to the appropriate maintenance tracks with Tested-by:s?
I'm going offline in a few hours and don't think I'll be around
much the next week or so.

Thanks.

 Thanks,
 Valery
 
 On 30 January 2015 at 01:22, Eric Wong normalper...@yhbt.net wrote:
  Valery Yundin yuval...@gmail.com wrote:
  Hi,
 
  Here you go:
  dfa72fdb96befbd790f623bb2909a347176753c2 is the first bad commit
 
  Thank you.  Can you give the following patch a try?
  I have not been able to reproduce the problem on my end.
  If it doesn't work out, I might be out of ideas for a bit :/
  Increasing --log-window-size will help you run longer without
  the error, but that's not ideal as it can also eat memory.
 
  ---8--
  From: Eric Wong normalper...@yhbt.net
  Subject: [PATCH] git-svn: destroy all tempfiles when reloading RA
 
  This may fix the errors some users are seeing with:
  write .git/Git_svn_hash_XX: Bad file descriptor
 
  Thanks to Valery Yundin for helping bisect the problem introduced in
  commit dfa72fdb96befbd790f623bb2909a347176753c2
  (git-svn: reload RA every log-window-size)
 
  Cc: Valery Yundin yuval...@gmail.com
  Signed-off-by: Eric Wong normalper...@yhbt.net
  ---
   perl/Git.pm| 6 ++
   perl/Git/SVN/Ra.pm | 1 +
   2 files changed, 7 insertions(+)
 
  diff --git a/perl/Git.pm b/perl/Git.pm
  index b5905ee..698018e 100644
  --- a/perl/Git.pm
  +++ b/perl/Git.pm
  @@ -1347,6 +1347,12 @@ sub temp_path {
  $TEMP_FILES{$temp_fd}{fname};
   }
 
  +sub temp_reset_all {
  +   unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
  +   %TEMP_FILEMAP = ();
  +   %TEMP_FILES = ();
  +}
  +
   sub END {
  unlink values %TEMP_FILEMAP if %TEMP_FILEMAP;
   }
  diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
  index 622535e..878679d 100644
  --- a/perl/Git/SVN/Ra.pm
  +++ b/perl/Git/SVN/Ra.pm
  @@ -397,6 +397,7 @@ sub gs_fetch_loop_common {
  $_[0] = undef;
  $self = undef;
  $RA = undef;
  +   Git-temp_reset_all;
  $gpool-clear;
  $self = Git::SVN::Ra-new($ra_url);
  $ra_invalid = undef;
  --
  EW
 --
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-16 Thread Mike 
Similar to the issue mintywalker originally mentioned on Jan 8th 2015, 
during a git svn clone I get a Bad File Descriptor error using:


git-svn version 2.2.2 (svn 1.8.8) on Ubuntu 14.04.

snip
r460 = 456377de3906d689c56e51af842e18abe086a980 (refs/remotes/origin/trunk)
A   client/binary/App_Client_v2.1.2.exe
r461 = 36848dbb7f417da2e381b61b68ff7b0d22a5bf7f (refs/remotes/origin/trunk)
write .git/Git_svn_hash_0WWL4a: Bad file descriptor
 at /usr/lib/perl5/SVN/Ra.pm line 623.


$ svn diff --diff-cmd diff -c 461
Index: client/binary/App_Client_v2.1.2.exe
===
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: client/binary/App_Client_v2.1.2.exe
===
--- client/binary/App_Client_v2.1.2.exe(revision 0)
+++ client/binary/App_Client_v2.1.2.exe(revision 461)

Property changes on: client/binary/App_Client_v2.1.2.exe
___
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property


Not sure if it helps or not, but here is the commit immediately after 
that one:


$ svn diff --diff-cmd diff -c 462
Index: interface/help/App_Client.exe
===
--- interface/help/App_Client.exe  (revision 0)
+++ interface/help/App_Client.exe  (revision 462)
@@ -0,0 +1 @@
+link ../../client/binary/App_Client_v2.1.2.exe
\ No newline at end of file

Property changes on: interface/help/App_Client.exe
___
Added: svn:special
## -0,0 +1 ##
+*
\ No newline at end of property

Unfortunately the repository is private, but it seems like a pretty 
simple commit that is causing the problem?


If you need more information please let me know.

Thanks.


--
Mike
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-13 Thread Eric Wong 
Minty mintywal...@gmail.com wrote:
 § git --version
 git version 2.2.1

What about git svn --version ?
(it'll display the SVN binding version, too)

 Any advice / pointers would be welcome -- I'd be happy to run any
 tests  I'm reasonably comfortable coding in Perl so happy to poke
 around where I can.

Great to know.  Unfortunately, I no longer have access to the repo where
I encountered the problem and haven't been able to reproduce it again,
either.

The first step is to find a (preferably) fast way to reproduce the issue
consistently.  If you can isolate which revisions and change patterns in
your private repo cause it, it should be possible to create a public
repo without confidential data in it which reproduces the problem.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-08 Thread Minty 
I appear to have hit a bug (or have data that the code fails on) while
importing an SVN repo to git.

I'm wondering if there is anything I can do to help find / fix the
cause, given I appear to have a fail-case.

Sadly I can't supply the SVN repo as the code is private.

What I did:

git svn clone https://www.example.com/dshfkjhfsjhsdkjfhsdf/nameofrepo

What I'm running:

MacOS Yosemite 10.10.1 (14B25)

§ git --version
git version 2.2.1

Built via MacPorts using: sudo port install git +svn

and updated today to the latest available.

The process was running for a few minutes and does appear to have
imported a lot.  The last few lines of output, including the error
(with paths/names anonymised)

r869 = 9823c89bbdfa9d51aeb0a16c539049ae96nd5d62 (refs/remotes/git-svn)
Dpath/to/stuff/Example1.java
Dpath/to/stuff/Example2.java
W: -empty_dir: path/to/stuff/Example1.java
W: -empty_dir: path/to/stuff/Example2.java
r870 = b1f06434b0b2f37a11be2ee5dfc6175bjs348545 (refs/remotes/git-svn)
write .git/Git_svn_hash_BmjclS: Bad file descriptor
 at /opt/local/lib/perl5/vendor_perl/5.16.3/darwin-thread-multi-2level/SVN/Ra.pm
line 623.

Any advice / pointers would be welcome -- I'd be happy to run any
tests  I'm reasonably comfortable coding in Perl so happy to poke
around where I can.

I've been using git for year (thanks! it rocks) and hoping I can avoid
having to (re)learn too much about SVN.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git svn import failure : write .git/Git_svn_hash_BmjclS: Bad file descriptor

2015-01-08 Thread Minty 
On Thu, Jan 8, 2015 at 12:43 PM, Minty mintywal...@gmail.com wrote:
 git svn clone https://www.example.com/dshfkjhfsjhsdkjfhsdf/nameofrepo

 r869 = 9823c89bbdfa9d51aeb0a16c539049ae96nd5d62 (refs/remotes/git-svn)
 Dpath/to/stuff/Example1.java
 Dpath/to/stuff/Example2.java
 W: -empty_dir: path/to/stuff/Example1.java
 W: -empty_dir: path/to/stuff/Example2.java
 r870 = b1f06434b0b2f37a11be2ee5dfc6175bjs348545 (refs/remotes/git-svn)
 write .git/Git_svn_hash_BmjclS: Bad file descriptor
  at 
 /opt/local/lib/perl5/vendor_perl/5.16.3/darwin-thread-multi-2level/SVN/Ra.pm
 line 623.

fyi - tried the same repo, same command under Ubuntu 14.04, using the
stock git-svn deb  it worked.

happy to help try debugging the problem on MacOS if anyone wants to
give me a pointer, but otherwise I'm good.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html