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

Re: New (1.5) feature questions -- things we need to address before a release can happen

From: Peter McNab <mcnabp_at_optushome.com.au>
Date: 2007-05-21 00:47:10 CEST

Karl Fogel wrote:
> "Mark Phippard" <markphip@gmail.com> writes:
>
>>> Generally it works well, however when the commit is "large" (I'm not sure,
>>> several megabytes or more or at least the commit time of a few minutes
>>> (???)) then we usually have problems where the slave has not synced up
>>> with
>>> the master yet and the client that committed it to the slave gets confused
>>> and starts giving errors. It has been possible but problematic to get
>>> things straightened out, and sometimes I've had a svnsync not go through
>>> and had to manually kick it and/or delete the svn:lock (I think that is
>>> the property) to get things going again.
>>>
>>> Is there a way to do a synchronous sync with the slave or some code magic
>>> behind the scenes that could be added in the client or slave server or
>>> master server to tell the client to wait a little longer to be synced
>>> up with the slave server correctly?
>>>
>>> I think what is happening is that the slave says "I've committed a certain
>>> version" and then at the end of the commit it checks that the slave server
>>> has that version which hasn't been synced yet and it gets confused.
>>>
>>> Thankfully this has not happened a whole lot but it has happened on
>>> multiple occasions. I'm telling my users that when they have a "large"
>>> commit (size or time is hard to determine) then to switch to the master to
>>> commit it and then switch back to the slave again.
>>>
>>> Any help, ideas, pointers, would be appreciated.
>>>
>> Seems like a problem that should be identified and fixed before we
>> release. Now that we have svnsync it would be super-cool if it could
>> be formally integrated into this so that you did not need a hook at
>> all.
>>
>
> A client-side solution might work. Take a client that's reading from
> a slave repository S, but whose commits go to a master M.
>
> 1. S is at revision R, M is at revision R
>
> 2. Now the client commits. Afterwards, M is at revision R+1, but S
> is still at revision R. (Assume the commit is large, so S can't
> sync up immediately.)
>
> 3. If the client knows that its commit went through to M, it can
> obey a rule that says: "Until S is at R+1 or higher, do all
> reads from M".
>
>
So long as R+1 is guaranteed to be the result of this clients commit and
not from another clients simultaneous action.

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 21 00:47:21 2007

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