[LLVMdev] Repository Layout

[Gordon Henriksen]

On Jul 1, 2007, at 4:47 PM, Reid Spencer <rspencer at reidspencer.com>  
wrote:

> 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, ...)

But, unless I misunderstand your suggested layout, that benefit would  
not extend to branches or tags, because you placed the project as the  
parent directory of the tag. This makes branches and tags much less  
useful, because they cannot be used symmetrically with the trunk(s) or  
created with a simple svn copy command, should more than one subfolder  
need to be tagged.

>> If the projects are too granular, merge them together.
>
> Perhaps, but that's not related to the issue at hand.

By "project", I was referring solely to the layout in source control,  
not any source code integration. Sorry for the imprecise language. I  
shall use "SVNROOT" instead.

>> 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.

As you note, that directory cannot be (practically) checked out  
because it will contain all branches and tags. I'm referring to a  
folder which transparently references other projects as a shortcut for  
checking out all of the trunks manually, precisely the scenario  
described in the Red Book.

>> 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).

Yes, exactly. But in your proposed layout, that only works for the  
trunk. That's because you flipped the path from SVNROOT/tags/tagname/ 
folder to SVNROOT/tags/folder/tagname.

> 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.
>>
>>
>>
>>
>>
>>

All I'm saying is this:

1. You'll cause yourself headaches unless the contents of $SVNROOT/ 
trunk is symmetrical with $SVNROOT/{tags,branches}/$name.

2. It sounds like you would be happier with fewer SVNROOTs.

But you should also consider whether this is simply a growing pain;  
cvs and svn are fundamentally different in that Subversion makes the  
management structure visible in the URL.

- Gordon