[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [PATCH] Issue 3942 - Provide new subcommand on svnadmin to create a lock

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 15 Jul 2011 18:28:39 +0200

> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: vrijdag 15 juli 2011 18:20
> To: Daniel Shahaf
> Cc: Bert Huijben; Noorul Islam K M; Subversion
> Subject: Re: [PATCH] Issue 3942 - Provide new subcommand on svnadmin to
> create a lock
>
> On Fri, Jul 15, 2011 at 12:16 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
> wrote:
>
> > If svnsync presents the lock token that's present on the master, and
> > hopefully the slave checks locks against the master during commit, the
> > commit is going to work isn't it?
>
> Apache proxies commits back to the master. When you are using svnsync
> to update the replica it is not going through that proxy. In my case
> it using file://, but in the book it uses a special Apache location
> that does not proxy. So no, it does not check against the master.
>
> > Point is: using 'svnadmin lock', despite creating locks on the slave's
> > FS, doesn't change the fact that those locks are *cached* locks, they
> > aren't binding/normative in any way.
>
> That would be the ideal but it is not true today. I also do not think
> svnsync even presents a lock token since there is no working copy
> involved to provide the token.

I don't think it is hard to implement to present the lock tokens via svnsync
as we can just retrieve them from the master (or even the slave) via the
existing ra api when syncing, but retrieving the tokens introduces some race
conditions

        Bert
Received on 2011-07-15 18:30:29 CEST

This is an archived mail posted to the Subversion Dev mailing list.