[xiph-cvs] Subversion tree layout proposal
giles at xiph.org
Mon Jul 7 10:58:00 PDT 2003
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?
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
> 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.
--- >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.
More information about the commits