OK, so this is definitely a win32 issue. I believe that the perl
script is simply creating .lock files too fast for Windows to keep up.
Simply trying again fixes the problem for me.
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3676,8 +3676,10 @@ sub rev_map_set {
"$db => $db_lock ($!)\n";
}
- sysopen(my $fh, $db_lock, O_RDWR | O_CREAT)
- or croak "Couldn't open $db_lock: $!\n";
+ my $fh;
+ my $tries=10;
+ for(; !sysopen($fh, $db_lock, O_RDWR | O_CREAT) && $tries>=0; $tries--) { }
+ if($tries <= 0) { croak "Couldn't open $db_lock: $!\n"; }
$update_ref eq 'reset' ? _rev_map_reset($fh, $rev, $commit) :
_rev_map_set($fh, $rev, $commit);
if ($sync) {
If this is a reasonable solution, I can go figure out how to properly
format a patch to the list.
-Nate
On Sun, Sep 19, 2010 at 10:42 PM, Nate Parsons <parsons.nate@xxxxxxxxx> wrote:
>
> Hello again,
>
> I realized I have git-cheetah running as well, so I killed
> explorer.exe (the only process using git_shell_ext.exe), and tried
> again. That's when I noticed that running 'git svn fetch' spawned two
> git processes and a perl process (which later spawned another perl).
> Is this something that should be happening?
>
> Thanks,
> -Nate
>
> On Mon, Sep 13, 2010 at 11:19 AM, Nate Parsons <parsons.nate@xxxxxxxxx> wrote:
> >
> > Hi everyone,
> >
> > I'm trying to switch to git, so I apologize in advance for my
> > ignorance. For this, I'm using cygwin git, version 1.7.1 to talk to a
> > svn server running 1.4.2.
> >
> > When I 'git svn clone' or 'git svn clone; git svn fetch', I sometimes
> > run into the following error.
> > > Couldn't open .git/svn/refs/remotes/0.0.0/.rev_map.b8cad480-e46b-48b4-8317-a683ee46c2bd.lock: Device or resource busy
> > > at /usr/lib/git-core/git-svn line 5210
> >
> > And when I 'git svn rebase'
> > > Couldn't open .git/svn/refs/remotes/git-svn/.rev_map.cc05479a-e8ea-436f-8d71-e07493b7796c.lock: Device or resource busy
> > > at /usr/lib/git-core/git-svn line 1528
> >
> > Sometimes the line number is different (578, I think?), but when I
> > retry the fetch command, it rebuilds the file corresponding to the
> > lockfile, and then continues a little farther before dying again.
> >
> > When I watch the directory in question, I see the lock file appear,
> > and then disappearing a short time after the script gives up.
> >
> > I don't have a series of steps to reproduce the problem, sometimes it
> > goes for an hour, and sometimes for just a few minutes/seconds.
> >
> > I do have TortoiseGit running my machine, but this issue happens even
> > when TGitCache.exe is not running. If some other instance of git is
> > accessing the repository, I don't know which or how.
> >
> > Thanks,
> > -Nate
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html