On Tue, Dec 01, 2009 at 11:40:20AM -, Jon Foster wrote:
> Have you got any comments on the two patches I posted
> on Friday?
Not yet, no time :-/
Sorry.
Stefan
"Jon Foster" writes:
> Have you got any comments on the two patches I posted
> on Friday?
I marked them, but haven't looked at them yet because they were zip
file attachments. I know you were having email problems, but that
doesn't alter the fact that I'm most likely to read patches that are
in
Hi,
Philip Martin wrote:
> Branko Čibej writes:
> > Do we want to support this local svnsync usage on Windows?
> Yes.
> > If we do,
> > someone must implement reliable local locking internally.
> That's easy, we just call apr_lock_file_create :)
Lockfiles have a big disadvantage: If the proces
Branko Čibej writes:
> Do we want to support this local svnsync usage on Windows?
Yes.
> If we do,
> someone must implement reliable local locking internally.
That's easy, we just call apr_lock_file_create :)
We know how to do it on Linux, it's even documented in the O_EXCL
section of the cre
Stefan Sperling wrote:
> On Fri, Nov 27, 2009 at 01:42:58PM +, Philip Martin wrote:
>
>> Stefan Sperling writes:
>>
>>
Would it be reasonable to add a "--local-lock-file FILENAME" option
to svnsync, which would turn off the current locking and use file
locking instead?
On Fri, Nov 27, 2009 at 01:42:58PM +, Philip Martin wrote:
> Stefan Sperling writes:
>
> >> Would it be reasonable to add a "--local-lock-file FILENAME" option
> >> to svnsync, which would turn off the current locking and use file
> >> locking instead? If so, I can work on a patch to do this
On Fri, Nov 27, 2009 at 01:53:31PM -, Jon Foster wrote:
> > But it only works if the synsync processes run on the host where the
> > target repository is located (i.e. you have to run synsync pulls from
> > a cronjob on the mirror, rather than triggering svnsync pushes from
> > a post-commit ho
Hi,
Stefan Sperling wrote:
> You can use tools like lockf or lockfile (part of procmail) for that.
Thankyou, I didn't know that existed. That saves me the hassle of
writing and testing my own locking code.
> But it only works if the synsync processes run on the host where the
> target repositor
Stefan Sperling writes:
>> Would it be reasonable to add a "--local-lock-file FILENAME" option
>> to svnsync, which would turn off the current locking and use file
>> locking instead? If so, I can work on a patch to do this.
>
> I think we need an approach that also works over the network.
Netw
On Fri, Nov 27, 2009 at 12:57:09PM -, Jon Foster wrote:
> Stefan Sperling wrote:
> > There is a much worse race condition, however.
>
> Yep, your mail arrived whilst I was testing this race condition in
> a debugger. I can confirm it's a real bug.
>
> But for me, the biggest problem with svn
Hi,
Stefan Sperling wrote:
> OK, I will commit it.
Thankyou.
> There is a much worse race condition, however.
Yep, your mail arrived whilst I was testing this race condition in
a debugger. I can confirm it's a real bug.
But for me, the biggest problem with svnsync's locking right now is
that
On Fri, Nov 27, 2009 at 11:04:26AM +, Philip Martin wrote:
> Stefan Sperling writes:
>
> > What about the patch below?
> >
> > [[[
> > * subversion/svnsync/main.c
> > (get_lock): The lock attempt is done in iteration N, and success is
> >checked in iteration N+1. Prevent the case where
Hi,
Stefan Sperling wrote:
> What about the patch below?
I've tested this, and it fixes the problem. Thanks!
Kind regards,
Jon
**
This email and its attachments may be confidential and are intended solely for
the use of the
Stefan Sperling writes:
> What about the patch below?
>
> [[[
> * subversion/svnsync/main.c
> (get_lock): The lock attempt is done in iteration N, and success is
>checked in iteration N+1. Prevent the case where svnsync attempts
>to take the lock in the very last iteration, doesn't chec
On Wed, Nov 25, 2009 at 07:28:22PM +, Philip Martin wrote:
> "Jon Foster" writes:
>
> > A patch is attached. The patch is against 1.6.6. I've tried to
> > keep the changes minimal, because I think this might be a candidate
> > for a Subversion 1.6.7 patch release.
>
> A minimal patch is so
"Jon Foster" writes:
> A patch is attached. The patch is against 1.6.6. I've tried to
> keep the changes minimal, because I think this might be a candidate
> for a Subversion 1.6.7 patch release.
A minimal patch is something like this:
Index: subversion/svnsync/main.c
16 matches
Mail list logo
