On Fri, May 17, 2002 at 03:52:20PM -0500, Karl Fogel wrote:
>...
> It's basically what's described in issue #517, except Mike Pilato
> suggested the following modification: instead of a file, have a
>
> svn:references
>
> (or "svn:external-sources" or whatever) property that can be put on a
> directory. The value of the property is a description of additional
> items to be checked out into subdirectories (the format of the
Right. So call it 'svn:extra-items' or something. svn:references is way to
geeky. It does not describe its end-user functionality.
> description is the same as the file format described in issue #517).
> So during a checkout, if you encounter this property set on directory
> "A/", then each item listed in the property's value will be checked
> out as a disconnected subdir of A/.
>
> Here, "disconnected" means that the subdirs do not get entries in
> "A/.svn/entries". They're simply there. Whether commits and updates
> recurse into such subdirs is something we can decide (maybe
I don't think we need to worry about the behavior at all. The behavior is
defined by our mixed-repository working copy model.
In short, "do the checkouts, the working copy will define the relationships
between the directories." There is no *new* behavior [beyond the behavior we
state for mixed-reps].
For example, I would think that an 'svn update' will update all working
copies under '.', whether they are from one repository or many. Note that
this is exactly the same behavior as CVS: the dirs get "hooked into" their
parents, and an update or commit will just incorporate them into their
operation.
Don't make it configurable whether it gets hooked or not. That will just
cause users no end of confusion (and this happens to me occasionally, where
a CVS working copy doesn't get hooked into its parent; thankfully, I know
how to edit CVS/Entries to manually hook it).
>...
> Anyway. This supports multiple-repository modules (something that I
> think *is* going to be important right away) simply. It adds no new
It absolutely will need to. I think of projects as one-per-repository, but
many other people on this list believe many-projects-per-repos. That isn't a
problem, and Subversion will support both models quite easily (it is just
policy for the repository/project admins).
BUT! (and you knew that was coming...)
What about the "cross-ownership" boundary? Subversion is composed using a
module description like this:
trunk http://svn.collab.net/repos/svn/trunk
trunk/apr http://svn.apache.org/repos/apr/apr/trunk
trunk/apr-util http://svn.apache.org/repos/apr/apr-util/trunk
trunk/neon http://svn.webdav.org/repos/neon/trunk
You're looking at three different realms of ownership. For our example
population of 1, we're batting 1.000 for multi-repository modules.
I will also note that the "reference node" concept cannot support module
descriptions similar to above without a TON of work. The "place URL into
REF1/FOO" isn't possible. You would have to have ownership of the target of
REF1. In the specific example above, we could define the references to
apr(-util) and Neon within svn/trunk. However, consider the case where some
people prefer to have 'db' in their working copy. There is no way [in my
world] where I'd support adding that reference to our mainline trunk. Thus,
those developers would be screwed, unless they could define a target for
trunk/db/ (which the "description file" approach can, but the refnode style
cannot).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 18 01:51:39 2002