Sounds good, thanks Peter!
It does appear, however, that the locking time on a repository
receiving commit goes way up, because it may depend now on a net
connection to some other repository that it has to confirm sync'dness
with. That is, repos A wants to avoid conflicts with B. So when you
commit to A, A syncs up with B, then receives the changes, merges,
then locks a new revision number while it checks that B *still* hasn't
changed, then finishes the commit. But that penultimate step, the
second check of B, involves a network connection, etc.
Certainly doable, just changes certain performance characteristics.
Post-1.0, of course...
-Karl
<peter.westlake@arm.com> writes:
> On 2001-12-04 17:17:00 Karl Fogel wrote:
> ...
> >Distributed, synchronized read-write repositories are hard because of
> >dealing with conflicts, a problem that is independent of how they
> >store their data.
>
> The best way is to avoid conflicts. I've used a system that would
> synchronise before checkout or checkin, and would only let you
> check out if the master repository wasn't available. Add to that
> the ability to move ownership of files around, and you should have
> something workable. Especially if you can send efficient tree deltas
> in both directions.
>
> In a nutshell:
>
> - at any moment, only one repository "owns" each versioned object.
>
> - if your site's repository is not the owner, sync before making changes.
>
> - you can check something out from a repository that doesn't own it without
> syncing, but that may give you an old version. You can't check in.
>
> - as a refinement, you can ask for your local repo to become the owner
> of an object, though this is harder in a non-locking system like svn.
>
> I really miss that source control system....
>
> Peter.
>
>
>
> ---------------------------------------------------------------------
> 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 Sat Oct 21 14:36:51 2006