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

On Sun, 20 May 2007, Mark Phippard wrote:

> DAV write-through proxy
> This has the potential to be a killer feature, but it is another one
> that is not heavily documented. There is a notes file, but it looks
> like it pre-dates the implementation in some of the details. This one
> looks fairly easy to turn on but could benefit from some more
> explanation about what it wants to accomplish with some real-world
> implementation scenarios. For example, it seems fairly important that
> the read-only "slaves" are updated after a commit. Presumably svnsync
> would be a good candidate for doing this. An example hook-based
> implementation would be useful. Also, some discussion on the
> ramifications would be useful. What if I do a commit, followed by an
> update and my mirror has not been updated yet? Likewise, what if
> another user does a commit, and then I do a commit by mirror has not
> been updated yet. Will that effect me?
>

I have been using Subversion 1.4.2 on a Win2K3R2 master server with
Subversion 1.5 r???? (I forget, updated last sometime in January)
pre-release on a Linux Redhat 4 server since mid-December.

I have a post-commit script that does svnsync from the master to the
server and do web-dav proyxing (is that the correct term?) on the slave
server so we can commit to the slave and it re-directs the commit to the
master.

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.

It is a VERY useful feature and it generally works well.

Thanks!

--
David Wayne Summers        "Linux: Because reboots are for hardware upgrades!"
david_at_summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint =  0B44 B118 85CC F4EC 7021  1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org