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.
(Recall that configurations in Subversion are just paths in the
repository, like any other branch or tag.)
I think I agree with Greg: per-file repositories are a "we can", not a
"we need" feature. In the example you give below, only per-dir
repository switching is necessary.
-K
> > 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