Subversion with multiple read/write replicated repositories

[Kis Gergely <ki...@mailbox.hu>]

Hello,

I would like to recommend subversion to my company, but there is one
feature subversion is currently lacking: the support for multiple
replicated repositories. The approaches known to me (svn::Mirror,
Svn::Push, svn-push) are not sufficient, because I need two way
synchronization. A maximum synchronization lag of 1-2 hours may be
acceptable. The revision numbers should be preserved across the
repositories. It should be possible to commit in the local repositories
even if the network links to the other repositories are down. The system
should support 10 or more connected repositories - I am thinking of a
hierarchical approach.

How many manmonths would it take to develop this sort of functionality?
My starting estimate is 3 months with a 4 developers to reach a state
where piloting is possible, and another 3 month with the same team to
reach production quality.

If this kind of feature was already discussed to death, please accept my
apologies. I couldn't find many references in the archive and the issue
tracker.

I also thought about a method to solve this problem.
Every connected repository would allocate an interval of revision
numbers, and use these numbers between synchronization runs. After the
synchronization, the repositories allocate a new interval (probably
including the unused revision numbers from the old interval). If the
intervals are large enough, even if the network links are down, commits
are still possible. 
What do you think? If it's crap don't hesitate to tell me, so I don't
waste more time thinking about it.

Thanks,
Gergely
 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion with multiple read/write replicated repositories

[Ben Collins-Sussman <su...@collab.net>]

On Wed, 2004-05-12 at 10:19, John Peacock wrote:

> This is never going to be 100% automatic if you are permitting writes to more 
> than one repository (due to possible conflicts).

Replication is the "holy grail" problem in databases, and even the
biggest companies with hundreds of engineers have been struggling with
it for decades... companies like Oracle.  Even Clearcase, which boasts
this feature, can't avoid the pain of forcing users to manually resolve
conflicts when two different VOBs attempt to synchronize.

So your estimate of a "few months" is way, way off.  We have no plans
for such a feature.  As John said, http://svk.elixus.org might be
sufficient for you.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion with multiple read/write replicated repositories

[John Peacock <jp...@rowman.com>]

Kis Gergely wrote:

> I would like to recommend subversion to my company, but there is one feature
> subversion is currently lacking: the support for multiple replicated
> repositories. The approaches known to me (svn::Mirror, Svn::Push, svn-push)
> are not sufficient, because I need two way synchronization.

See also svk:

	http://svk.elixus.org/

which does support two-way mirrors, but possibly not in the way you expect.

> A maximum synchronization lag of 1-2 hours may be acceptable.

This is never going to be 100% automatic if you are permitting writes to more 
than one repository (due to possible conflicts).

> The revision numbers should be preserved across the repositories.

This is going to be the biggest problem, because the revision number is merely a
monotonically increasing value.  You cannot commit on one mirror and
simultaneously commit to another and have the revision numbers mesh (without
doing what you suggest and have multiple blocks of revision numbers which are
only used for commits.

If you can lose this constraint, you can get very close today with svk certainly 
and thus SVN::Mirror.  IMHO, the revision number is an artifact of the 
repository structure and it should not be used as an external datapoint (say to 
retrieve a specific set of files) except in very restrictive circumstances. 
Good tagging procedures serve this need very well.  Similarly, the CVS 
$Revision$ tag was never intended to be used as a file version (though many 
people have done so over the years).

> It should be possible to commit in the local repositories even if the network
> links to the other repositories are down. The system should support 10 or
> more connected repositories - I am thinking of a hierarchical approach.

svk supports disconnected transactions.

HTH

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org