Thanks for the tip. I didn't know about svn:externals.
It seems to support pulling in trees from other repositories. While
that by itself is a good thing, I think the design keeps it from
solving my problem.
What I am really looking for is a format of a property like what's
below (we'll call it svn:internals). Suppose I had a tree that looked
like this:
/common
/resources
/tools
/projects
/projects/calc
with files in each directory.
The svn:internals property would be:
$ svn propget svn:internals /projects/calc
/common
/resources -r21
And if I checked out /projects/calc, I could do so in a way that would
PRESERVE the tree's structure in my own working copy, rather than
building the other directories into Calc, which is the behavior of
svn:externals:
$ svn checkout http://svn.example.com/projects/calc
A projects/calc
A projects/calc/Makefile
A projects/calc/integer.c
A projects/calc/button.c
Checked out revision 148.
Fetching internal item into /common
A common/some
A common/other
A common/files
…
A resources/andmore
A resources/files
Checked out revision 21
So the working copy tree would be a subset of the repository tree,
with all the directories checked-out mirroring the directories in the
repository. What I'm trying to get away from is having to put the
"common" and "resources" directory, which are common to many projects,
as subdirectories inside the "calc" project. Otherwise a check-out of
the entire repository will get duplicate code into the working copies
-- as many copies of the common shared libraries as there are
projects.
Does that make sense? Is there no way to mark that one directory
should bring other directories with it, without making those
directories have to belong within the first?
On Mon, 18 Oct 2004 13:02:06 -0400, François Beausoleil
<fbeausoleil@ftml.net> wrote:
>
>
> Andrew Arnott wrote:
> > I have the exact same problem here. Right now, I use a common
> > top-level "common" directory. And my fellow developers also refuse to
> > get the whole tree, leading to this problem.
>
> > On Mon, 18 Oct 2004 09:38:29 +0200, Klimek Manuel <m.klimek@el-me.de> wrote:
> >>Now we've got that header.h which is common to multiple
> >>projects. As far as I understood the concepts of the
> >>subversion implementation it should be fairly easy
> >>to have common/ in one project be just a link to common/
> >>in the other project. But if I use 'svn cp', commits
> >>into one project won't be visible in the other project.
> >>If I use some toplevel common/ directory, the developers
> >>have to checkout the whole subeversion tree, which they
> >>refuse to do...
>
> What you're both looking for is svn:externals. This is a property you
> set on a directory, which will checkout another portion of a tree. See
> svn help propset for more information, as well as the book.
>
> Bye,
> François
>
>
--
Andrew Arnott
Web Developer
Brigham Young University
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 18 20:02:22 2004