[LLVMdev] Repository Layout

[Gordon Henriksen]

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

If the projects are too granular, merge them together. It might, in  
fact, be appropriate to use a single project root for the totality of  
llvm. 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.

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.

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.

— Gordon

[1] http://svnbook.red-bean.com/en/1.0/ch07s03.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070701/2aeb5878/attachment.html>