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

Re: working copy storage for RA properties

From: Branko Čibej <brane_at_xbc.nu>
Date: 2000-12-06 00:47:58 CET

Jim Blandy wrote:

> Karl Fogel <kfogel@galois.collab.net> writes:
>> Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
>>> You don't "svn add" a file to a configuration. Configurations are
>>> effectively what CVS modules are (or rather, CVS modules are a subset of
>>> configurations). OTOH you could always require that "svn add" under a
>>> configuration needs an explicit repository parameter.
>>> These beasties can be extremely useful for hooking up distributed
>>> repositories, among other things.
>> Oh, I'm sorry Branko, I misunderstood your proposal.
>> I think what you're talking about (CVS modules-like functionality) is
>> already planned via "union directories"; if you haven't seen JimB's
>> description of those, let me know and I can dig it up for you. It's
>> in the archives somewhere.
> Well, union directories don't handle pulling together things from
> different servers.
> I wonder what kind of meaning one can assign to transactions if one
> has a working copy assembled from multiple servers. Are transactions
> meaningful across multiple independent servers?

I shudder to think about it.

You could argue that if it's in different repositories, it's not
related, so you don't have to worry about keeping changes atomic. This
argument implies that you're not dealing with a distributed repository,
just with a working copy pulled together from different repositories.

Having real distributed repositories (such as provided by ClearCase
Multisite, for instance) is an entirely different problem: you'd really
need distributed transactions, too. That's post-2.0, IMHO.

Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/
Received on Sat Oct 21 14:36:16 2006

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