Hi Gordon,
> I'm finding the current layout a bit frustrating, not to mention
> that it breaks all the documentation. [...] I would rather see it
> laid out like this:
>
>
> >
> trunk/llvm/...
> trunk/stacker/...
> trunk/java/...
>
>
> branches/llvm/...
> branches/stacker/...
> branches/java/...
>
>
> tags/llvm/...
> tags/stacker/...
> tags/java/..
Reid,
This is a common problem with Subversion. I wouldn't recommend using
the layout you suggested here, though. Although it's "just" a
convention, please keep the standard layout at the root of each
project. (You're proposing interceding a directory layer between
trunk, branches, and tags, etc. I don't think you'll find that it
solves many management problems.)
I wasn't trying to solve any management problems. I see both schemes
(project at top vs. trunk/tags/branches at top) as having basically the
same management issues. What I was trying to achieve was:
a) a single URL for checking out all llvm-project software. Putting
trunk/tags/branches at the top would give us:
http://llvm.org/svn/llvm-project/trunk as the root of all software.
Without this, you would have one root for each sub-projects (llvm,
stacker, java, ...)
b) not having to fix all the documentation that references paths to
insert a "/trunk" into the path.
If the projects are too granular, merge them together.
Perhaps, but that's not related to the issue at hand.
It might, in fact, be appropriate to use a single project root for the
totality of llvm.
We have that: http://llvm.org/svn/llvm-project.
Getting this correct is by far the most important decision to be
made, IMO. It's very easy to check out a subdirectory of a project,
but much harder to check out a union of several projects.
if tags/trunk/branches was at the top level then getting the "union of
several projects" is achieved by just checking out
"trunk" (http://llvm.org/svn/llvm-project/trunk). Again, I'm not sure
how this is relevant to the original issue. Am I missing something?
However, if a union of several projects is necessary, Subversion does
have an svn:external property[1] which can be used to create precisely
that. It's much more complicated to tag or branch such a beast,
however, so it is strongly recommended that such a thing not be used
as a unit of release.
I'm aware of svn:external and I don't think we should be using it for
internal repositories. We *might* want to use it to integrate another
repository, but I know of no such need currently and can't see it
arising in the future.
Anton, as Reid mentioned, there's absolutely no need to worry about
wasting repository space with copies. However, since copies are so
incredibly cheap on the server, there is a need to worry about wasting
developer hard disk space. At the client, copies are much more
expensive with Subversion than with CVS, so your intuition is still
very useful.
Yes, on the client side, copies are definitely more expensive. This just
underscores the need to set up a way to get "trunk" easily and avoid all
the copies in tags and branches. For example, consider doing something
like this:
svn co http://llvm.org/svn/llvm-project
Right now, what that will get is you is the trunk of all projects and
all the tags and branches for all those projects. Clearly this isn't
desirable. For just the llvm sub-project, this would involve checking
out 28 copies of the llvm source code.
If we had trunk/tags/branches at the top then it is much easier to get
the single copy of the latest software with just:
svn co http://llvm.org/svn/llvm-project/trunk
So, in summary, I'm not quire sure I understand your original caution
about using this approach. What are the management headaches that we
would incur? Are they any higher than putting trunk/tags/branches one
level lower (by having the module name first)? A little more detail
would be helpful.
Thanks,
Reid.
