What happens when a user attempts a commit, against a copy
of the workspace that isn't up-to-date? For example
suppose the copy repo has version 114. Since then
the main repo has gone to 116. The files that the user
happens to be checking in as part of the change set
are what were changed on 115 and 116?
thanks!
donald
On Thu, Dec 12, 2002 at 08:57:19PM -0800, Justin Erenkrantz wrote:
> As I have mentioned before, I created a set of (small) patches to
> mod_dav_svn that allows for a master/slave replication model using
> WebDAV.
>
> A slave repository has a local copy of the repository and will
> respond to all read operations. For any write operations, it will
> transparently pass through the write operations to the master. On
> completion of the commit, the master server will update the slaves
> via a post-commit hook (currently using svnadmin incremental dumps).
>
> My implementation is such that a client will only interact with a
> slave server - it has no knowledge of the master server. This allows
> the beginning of scalability for large SVN repositories with many
> users doing reads.
>
> This is different from a transparent caching HTTP proxy in that a
> slave doesn't have to contact the master to fetch information it
> hasn't yet received. And, this isn't multi-master replication where
> you can commit to a slave independently of its master (which is where
> you need the repository GUID). This approach lives somewhere in the
> middle.
>
> I've posted before about contributing this back to the trunk, but
> have received zero feedback so far. Is there *any* interest in this?
> Would anyone like to see a branch with this functionality? -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 13 16:30:01 2002