SVN->GIT link broken?

[John Ralls]

On Mar 26, 2013, at 11:49 AM, Derek Atkins <derek at ihtfp.com> wrote:

> 
> I'm trying to understand why you use two locks, but I think it's because
> the first lock is used as the trigger and the second lock is used to make
> sure only one copy runs at a time.  So yes, I can add a "proc lock" in
> there to make sure only one instance runs at a time.  Then the only thing
> I need to do is handle the case where the push to github fails.

No, the trigger is the "knock" from code.gnucash.org. I use two locks as a semaphore so that there's never more than one running and one waiting, because any git svn fetch will get all of the changes so there's nothing gained by having a bunch of then queued up. The outer lock acts to prevent racing while the inner lock is getting set.
You wouldn't need that because your processes are running on a timer rather than a commit hook.

I'd use flock -n. There's no need for a job to wait when another is going to come along in a minute anyway. Move the rm inside the lock and check the lock (without the -n) in the commit hook to prevent a race between clearing, setting, and processing.

Do you want git-svn-mirror to back off or to fail with an exit code if there's a problem with Github? If it backs off it will hold the lock, perhaps for a long time.

Regards,
John Ralls