[xiph-cvs] Subversion tree layout proposal
Brendan Cully
brendan at xiph.org
Mon Jul 7 10:08:14 PDT 2003
The switch from CVS to Subversion is a good chance to go over the
layout of our current source trees. The most obvious flaw in the
current layout is that there are two repositories, but I think there
are other areas that could use improvement. Here's a proposal for the
new layout, to get discussion going:
Proposed subversion tree layout
-------------------------------
There seems to be a consensus that the top level of the SVN tree
be divided into tres partes per SVN custom:
/trunk (CVS HEAD)
/branches (CVS branch)
/tags (CVS tag)
The structure of the three top-level trees is largely identical
(I'll mention differences later), so I'll start with the /trunk tree.
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.
Actually in some cases we can use a three-level namespace. For
instance I think the language bindings for the libraries could be
children of the library tree.
We can also use a shared space, for convenience/portability functions
that are project-agnostic (like the httpp library, or the m4 macros).
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. People that
want Ogg output will always use ices2, but people that want MP3 will
always use ices1. We could make ices1 a branch, but I think this
causes confusion. Probably the best solution is to rename one of
them. Comments are especially welcome here.
The only tree I know well is the icecast tree, so I'm sure there will
be lots of mistakes, but here's how I might rearrange the current
tree:
/trunk
/ao
/lib
/python
/common
/m4
/avl
/httpp
/log
/net
/thread
/timing
/icecast
/icecast
/ices
/libshout
/lib
/perl
/python
/liveice
/liveice
/liveice-xmms
/ogg
/lib
/python
/tools
/paranoia
/speex
/tarkin
/theora
/lib
/vp32
/vorbis
/lib
/oggdrop
/positron (??? Maybe this should be filed elsewhere? ???)
/python
/tools
/tremor
/win32sdk
/speex
/tarkin
Not mentioned (I don't know what they are):
BlueberryArmageddon, MTG, greenremote, masktest, mgm, postfish,
snatch, w3d
Not mentioned (useless?):
glacier, ice2, iceberg, icedir, icesource, icetools, liblisten,
newdir
Tags (releases)
---------------
The tag tree could mirror the layout of the trunk tree, with the
release number as a subdirectory of the project being released.
Metaprojects can be tagged as well as individual releases. In this
case the format could be project/version/subproject-version
(eg: libshout/2.1/lib-2.1). This difference makes it easy to see which
individual project releases comprise the metaproject. Since there will
only be one project release per metaproject, there will be no clutter.
Some examples:
/icecast/ices/2.0.1
/icecast/libshout/lib/2.0.1
/icecast/libshout/python/2.0.2
/icecast/libshout/2.1
/lib-2.1.0
/perl-2.0.3
/python-2.0.2
Branches
--------
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 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. In SVN, branches are very cheap and I
think it makes the tree more consistent. For example, as soon as I
release libshout 2.1, I create /branches/icecast/libshout/2.1 and then
copy that branch over to /tags/icecast/libshout/2.1.
Ok, that's a dump of my thoughts. I'm sure lots of people will have
better ideas, so fire away.
-b
--- >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
mailing list