On Thu, Sep 30, 2010 at 18:00, Nate Parsons <parsons.nate@xxxxxxxxx> wrote:
> 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.
Sounds like something that might do with a non-hacky solution, but I
don't know what that would be.
> - Â Â Â 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) {
FWIW I think this is more readable, but maybe we want to retry on all
platforms:
my $fh;
if ($^O eq 'MSWin32' or $^O eq 'cygwin') {
# Try 10 times to open our lock file, in case Windows is lagging
for my $try (1..10) {
sysopen($fh, $db_lock, O_RDWR | O_CREAT);
last if $fh;
}
} else {
sysopen($fh, $db_lock, O_RDWR | O_CREAT);
}
warn "Couldnt open $db_lock: $!\n" unless $fh;'
--
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