SVN->GIT link broken?

John Ralls jralls at ceridwen.us
Tue Mar 26 12:56:19 EDT 2013


On Mar 26, 2013, at 9:17 AM, Derek Atkins <warlord at mit.edu> wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>>> We'll (I'll ;-) ) have to add some error handling to the push_repo
>>> function in git-svn-mirror (you're still using that, right?) to make
>>> it die if the push fails. Then your cron script can just test it and
>>> re-touch if it fails.
>> 
>> Alternatively, push_repo could handle the error on its own with an
>> exponentially-timed retry period. The only concern I have about that
>> is that there's no way to tell the difference between a temporary
>> outage and Github doing something that requires human intervention --
>> but I suppose that's also true of re-touching your sentinel file.
> 
> Well, a backoff would work, but that's not all the potential errors that
> happen.  I can forward you some of the emails I get with the various
> emails from the svn->git migration.  Sometimes I get a 'git error' about
> a file that doesn't exist (my guess is that this is from the svn->git
> portion).  Only once or twice did I see an ssh error pushing to github.

OK. Forward the emails and we can discuss which ones merit handling inside of git-svn-mirror, which can be ignored, and which require human intervention, then set up error handling accordingly. There should probably be a limit on the number of retries which might need to survive from one instance to the next, after which you get a "something's really wrong" email.

> 
>> BTW, why a cron job instead of an SVN commit hook?
> 
> In order to change the user so that I didn't have to make sure everyone
> with an SVN account could directly write into gitolite..  I wanted to
> make sure that the push into gitolite only happened from a single user,
> and the best way I could think of to do that was via a cron job.

OK. Note that if git-svn-mirror does a backoff you'll need locking in your cron script. You might consider killing a previous instance if the sentinel file is reset indicating another commit needs processing.

Regards,
John Ralls


More information about the gnucash-devel mailing list