Hi,
On Tue, March 26, 2013 12:56 pm, John Ralls wrote:
> 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.
>
Here are a few of the errors I saw over the weekend:
Running git svn fetch
fatal: Unable to create
'/u1/home/git-svn/git-svn/gnucash-htdocs/.git/refs/remotes/svn/published.lock':
File exists.
If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
error: failed to run reflog
gc: command returned error: 255
---
Running git svn fetch
mv: cannot stat
`/u1/home/git-svn/git-svn/gnucash-docs/.git/objects/pack/pack-31cc45b7482ee4b7cf3b5e987f6a2927bb2306ce.pack':
No such file or directory
error: failed to run repack
gc: command returned error: 255
---
Running git svn fetch
remote: ssh: connect to host github.com port 22: Connection timed out
remote:
remote: fatal: The remote end hung up unexpectedly
remote: ssh: connect to host github.com port 22: Connection timed out
remote:
remote: fatal: The remote end hung up unexpectedly
remote: Update script found and executable
>>
>>> 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
Yeah, right now it IS possible for two copies to run if the first run
takes more than 60 seconds to complete and there were two svn commits
back-to-back but crossing the cron job execution. I.e, if you get:
svn commit
cron execution 1
svn commit
cron execution 2
cron job 1 completes
cron job 2 completes
This situation *is* possible given the current implementation. One way I
could fix this would be to make sure cron job 2 cannot start until after
cron job 1 completes. Of course I would need to make sure the lock
disappears if the cron job crashes, to make sure it's not completely
dependent on a complete run to unlock.
The cron script is pretty dumb and straightforward:
#!/bin/bash
#
trigger=/home/svn/repo/tmp/trigger
HOME=${HOME-/home/git-svn}
# Only run this if we've been tickled
if [ ! -f $trigger ] ; then
exit 0
fi
rm -f $trigger
# Iterate over each repo and sync to gitolite
#echo "cd $HOME"
cd $HOME
for repo in gnucash gnucash-docs gnucash-htdocs ; do
./git-svn-mirror update git-svn/$repo
done
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
