[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-05 00:26:05 CET

Greg Stein wrote:

> Seperate repositories at the file level seems over-the-top to me.
> Per-directory is fine, but per-file? No way... that just feels like it will
> get confusing as hell for the user.
>
> Which file is from where? What happens when you add a file?

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.

> This just feels like a "we can build this, so let's do it" feature. I like
> to take the pointer of view of "a feature exists because we *should*, not
> because we *can*."

Nope, far from that. For instance, the top of the Subversion SVN tree
could be a configuration, saying "take apr from
apr.apache.org/home/cvspublic, take neon from www.webdav.org/neon, take
everything from svn.tigris.org/subversion." And that's just a simple
example. In practice you'd be able to have a configuration track a
certain version or tag in a foreign repository, e.g., pick up only those
parts of APR tagged APR_STABLE, or whatever.

All of this is post-1.0; we just have to keep in mind that we may want
to implement something like that. That doesn't mean that repositories
should be per-file *now*. Directory entries should inherit that property
from their parent.

-- 
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.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.