> > I also agree. While there is a use case there, it's fraught with
> > unclean edges and hard-to-explain consequences. Better for us to keep
> > it simple: if people want to pick and choose among entries, that's
> > what a depth-0 parent directory is for.
>
> We were discussing issues like this yesterday at our meeting concerning
> CVS to Subversion migration. This feature will help us enormously.
>
> Could I ask you to think about a couple of other things which are
> related to this:
>
> 1. In most of our projects there are two types of module - one which
> is being worked on and on which is being called but is actually a part
> of another project. I.e., I might only need to use the interface to
> something. It would be very nice if a directory could be flagged as
> read-only and actively prohibit commits.
svn:externals has this property: it downloads source code from another
repository and prevents commits when committing the container.
> 2. In CVS directories from other parts of the source tree can be
> checked out into a working copy and we make extensive use of this. I
> can see that this could be tortuous for Subversion but it is very
> useful. This proposal is part way there, but relies on all the possible
> subdirectories being in the same directory in the repository. I know
> this is like externals, but we have never been happy with externals and
> I think everyone understands the problems with them.
This can be achieved as follows:
Say you have projects /foo-1 and /foo-2 where /foo-2 also is a
subcomponent of /foo-1. Now you can create an (empty!) subdirectory in
the /foo-1 module - say /foo/bar - and then switch the directory to
the /foo-2 tree. Now, commits to /foo/bar will be sent to /foo-2 and
commits to /foo-2 will be pulled into /foo/bar.
HTH,
Erik.
PS: Please start a separate thread if you want to discuss 'related'
stuff, or if you want to send comments on this mail. We need to keep
this thread 'clean' for the design discussion of depth
other-than-infinity checkouts.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 14 11:43:01 2006