You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Klimek Manuel <m....@el-me.de> on 2004/10/18 07:38:29 UTC
Tree-internal real links
Hi,
I checked the web and the mailing lists but surprisingly
didn't find a reference that anybody had the same problem
that I have now (which could mean it's trivial :-)
I've got a big subversion tree containing multiple
projects. Now because subversion isn't able to checkout
only part of the directory structure without a lot of
playing around, the developers just check out 'their'
project subtree to work on.
base/
proj_A/
common/
header.h
proj_B/
common/
header.h
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...
Now of course I can create some post-commit hook to
automagically delete the common/ directory and set
the link to the new revision. I just thought that
the concept of subversion should allow such a 'real link',
and wondered if I missed some easy solution.
Apart from that we find subversion to be a really fine
solution for our projects :-)
best regards,
Manuel
--
Manuel Klimek
EL-ME AG
Phone: +49 8752 864 0
Email : m.klimek@el-me.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Tree-internal real links
Posted by Erich Enke <ep...@ruffdogs.com>.
François Beausoleil wrote:
>
> 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.
>
svn:externals, though it may be working to some satisfactory level for
other users and their uses, is not robust enough for my uses.
There are several open source projects that we track and modify to our
needs, many of which also track some other project themselves and have
to tweak those subprojects in order to function. So we have the
following repository layout:
SVNROOT/
our-project1
trunk
tags
branches
our-project2
sub-project1
trunk (our changes to mid-vendor's changes of
vendor's source)
mid-vendor-branches (tracks modifications made by
3rd party to original source)
sub-project2
(similar)
our-project3
.
.
vendor (holds pristine, original source projects)
open-source-proj1
trunk
tags
open-source-proj2
(same)
This sort of setup is necessary for if we want to apply selectively
mid-vendor changes, or anticipate a mid-vendor's release. Also, this
allows several such projects to track something like the linux kernel
while all having a common history (so that we don't have several full
copies of the linux source tree floating around in the repository,
taking up space).
What I would love to be able to do is to make a
repository-internal-symlink from
SVNROOT/our-project2/sub-project1/vendor ->
SVNROOT/vendor/open-source-proj1/trunk.
If I use svn:externals, I can't do
svn ps svn:externals '.
svn://host/SVNROOT/vendor/open-source-proj1/trunk' .
...when in SVNROOT/our-project2/sub-project1/trunk because it can't
assign to itself or somesuch. If instead I do
svn ps svn:externals 'trunk
svn://host/SVNROOT/vendor/open-source-proj1/trunk' .
...when in SVNROOT/our-project2/sub-project1, this doesn't have enough
desired behavior. I want to be able to move things around, and not have
my programmers have to worry about svn:external stuff, indeed not to
even have to know it is there.
The problem is particularly salient when trying to diff and merge. You
can't do it against a svn:externals'd directory because it isn't there
in the repository, something I was trying to get around with the first
example.
What I want and need is something exactly like the unix symlink ability,
where you can tell it's a symlink from ls if you need to, where you can
descend into it however if you need to also, so that if you "symlink
off" a directory to a new location, it doesn't break functionality.
If there is any such functionality existent, I would love to hear it.
Otherwise, I suggest this as a feature request.
Erich Enke
Ruffdogs.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Tree-internal real links
Posted by Andrew Arnott <an...@gmail.com>.
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
<fb...@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....@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
Re: Tree-internal real links
Posted by François Beausoleil <fb...@ftml.net>.
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....@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Tree-internal real links
Posted by Andrew Arnott <an...@gmail.com>.
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.
Honestly what I'd like to see is a way to see the entire tree in
Subversion, "checkmark" certain directories that I want to check-out,
and have the "dependencies" automatically checked in their respective
directories as well, which may not be in descendent directories of the
selected ones. While part of this may be an issue for TortoiseSVN, I
believe setting up "dependency" properties in Subversion in some
standard way so that Subversion command-line will automatically
check-out the requested directories and their dependency directories,
while preserving the entire tree structure to keep the relative paths
within the projects working, would be great!
Maybe this is somehow already implemented. I haven't heard anything
to lead me to believe that it has been, though.
On Mon, 18 Oct 2004 09:38:29 +0200, Klimek Manuel <m....@el-me.de> wrote:
> Hi,
>
> I checked the web and the mailing lists but surprisingly
> didn't find a reference that anybody had the same problem
> that I have now (which could mean it's trivial :-)
> I've got a big subversion tree containing multiple
> projects. Now because subversion isn't able to checkout
> only part of the directory structure without a lot of
> playing around, the developers just check out 'their'
> project subtree to work on.
> base/
> proj_A/
> common/
> header.h
> proj_B/
> common/
> header.h
> 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...
> Now of course I can create some post-commit hook to
> automagically delete the common/ directory and set
> the link to the new revision. I just thought that
> the concept of subversion should allow such a 'real link',
> and wondered if I missed some easy solution.
>
> Apart from that we find subversion to be a really fine
> solution for our projects :-)
>
> best regards,
> Manuel
>
> --
> Manuel Klimek
> EL-ME AG
> Phone: +49 8752 864 0
> Email : m.klimek@el-me.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
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