[xiph-cvs] Subversion tree layout proposal

[Ralph Giles]

On Monday, July 7, 2003, at 06:08 pm, Brendan Cully wrote:

> Our current tree is flat - every piece of code that can be
> independently released gets its own top-level directory. Now that we
> have a large number of projects, I think this is becoming a bit
> unwieldy (and probably also a little confusing for new users). I
> suggest we create a two level tree, where the top level is a
> metaproject, like icecast, vorbis or theora. I guess this would
> correspond roughly to the way the web sites are divided.

 From my perspective we can easily cut down the clutter by grouping some 
of the tools and dependencies together, without losing the benefits of 
a flat namespace. I think your approach makes sense for icecast with 
all it's componently, but it isn't worth adding replacing vorbis with 
vorbis/vorbis (or codecs/vorbis) just to get rid of vorbis-tools, 
vorbis-python, and vorbis-plugins. It is worth renaming some things to 
a sort puts things together in this scheme.

> I think we have a special problem with ices, though I could be
> biased. The problem is that we have two parallel lines of development,
> neither of which is ever likely to supersede the other.

How about ices1 and ices2?

> /trunk
>  [...]
>  /common
>     /m4
>     /avl
>     /httpp
>     /log
>     /net
>     /thread
>     /timing

Currently these are only common to icecast, so I think they should go 
there. m4 is a good candidate for moving to the top level if someone 
generalizes the macros to work with other packages.

> Not mentioned (I don't know what they are):
>   BlueberryArmageddon, MTG, greenremote, masktest, mgm, postfish,
>   snatch, w3d

As jack mentioned on irc, these are all tangencial projects (except for 
w3d which is part of tarkin) and should probably be moved to either a 
separate repository directory or a separate repository.

> Like tags, but the names may be more descriptive than simple version
> numbers. Eg: icecast/libshout/1.0 or ogg/lib/zerocopy. I don't see the
> need for metaproject branches, but if they were used they would look
> something like icecast/rtsp/icecast, icecast/rtsp/ices etc.

I think this in general, but we'll probably want to be less formal, for 
example there may be speculative projects involving several 
normally-separate modules.

> I think we should make it a rule that every major.minor combination
> gets an automatic branch built at release, not just when/if we need to
> do updates to the branches.

This is silly. With all the clutter you'll never see the development 
work. As you say, branching is cheap. A better idiom is to copy 
something to branches/ make changes and then move it to the new release 
tag when you're done with the fixes. Remeber the history follows the 
files, not the filenames like in cvs, so you don't lose anything by not 
having the branch available all the time.

  -r

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'cvs-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.