[LLVMdev] Repository Layout

[Reid Spencer]

Hi Gordon,

On Sun, 2007-07-01 at 08:22 -0400, Gordon Henriksen wrote:
> On 2007-06-30, at 18:36, Reid Spencer wrote:
> 
> 
> > 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.

> 
> 
> — Gordon
> 
> 
> [1] http://svnbook.red-bean.com/en/1.0/ch07s03.html
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev