This is the mail archive of the
mailing list for the Cygwin project.
Re: git-svn hang starting with 20110721 snapshot.
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 3 Aug 2011 10:44:27 +0200
- Subject: Re: git-svn hang starting with 20110721 snapshot.
- References: <4E383AC9.firstname.lastname@example.org>
- Reply-to: cygwin at cygwin dot com
On Aug 2 10:58, David Rothenberger wrote:
> I use git-svn extensively in my day-to-day work, and I noticed with
> recent snapshots that some of the git-svn commands are hanging. I
> narrowed it down to the 20110721 snapshot. 20110713 is the last one
> that works fine.
> I realize this isn't exactly a STC, but I don't have the time right
> now to narrow it down further (or the skills, really). I've attached
> a script which reproduces the problem. It requires svn and
> git-svn. In the script, the first "git svn init" command hangs with
> 20110721, but the entire script succeeds with 20110713.
> I hope this is enough information to track down the problem, because
> I was absolutely LOVING the speed increase in 20110801.
This is not enough for me. I tried your script on W7 32 bit and Server
2008 R2 64 bit, using Cygwin from CVS as well as the 20110801 snapshot,
in in no case can I reproduce a hang. The script runs fine (and fast):
Creating an SVN repository and workspace.
Checked out revision 0.
Transmitting file data .
Committed revision 1.
Initializing with git svn.
This hangs with recent snapshots.
Initialized empty Git repository in /tmp/git-svn-problem.2528/work/trunk/.git/
r1 = 3a690f391f65e05607235e13e2baf15af222ea6a (refs/remotes/trunk)
Checked out HEAD:
Making a change in svn, then doing git svn rebase --all.
git svn rebase --all also hangs.
Transmitting file data .
Committed revision 2.
HEAD is now at 3a690f3 Initial version
r2 = 688e627bde2e5b2cdf7526edb9b34a21e2f816a2 (refs/remotes/trunk)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/trunk.
I see only one change in the 20110721 snapshot which *might* account for
this problem and that is the FIONREAD stuff, but actually even that is
unlikely since it just changes the error code returned from the ioctl
call (ENOTTY instead of EINVAL).
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple