Thanks for the help, I just didn't make the connection
from 'external' to be used as 'internal link' :-)
Francois, as far as I read in the mailing lists, you
will be able to achieve this behaviour (not fully automagically)
if the checkout semantics of cvs will be cloned in subversion.
This would solve my problem, too, but after what I read
I think this will still take some time until it is implemented.
Your idea with dependencies on directories is really nice,
but it would alter the checkout semantics:
svn co <...>/some/dir/sub
would have to checkout locally into
./some/dir/sub instead of just ./sub, because otherwise
it would have to access ../, which could be not even writable
if sub depends for example on <...>/some/other.
But the idea is nice nonetheless :-)
Greetings,
Manuel
> -----Ursprüngliche Nachricht-----
> Von: Andrew Arnott [mailto:andrewarnott@gmail.com]
> Gesendet am: Montag, 18. Oktober 2004 20:02
> An: François Beausoleil
> Cc: Klimek Manuel; users@subversion.tigris.org
> Betreff: Re: Tree-internal real links
>
> 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 Wed Oct 20 15:38:25 2004