[xiph-cvs] Subversion tree layout proposal

[Brendan Cully]

(My proposal, with minor mods (I moved positron up a level, and rewrote
the lib/python/perl directories as, eg, ao, ao-python, ao-perl) is at
http://wiki.xiph.org/SVNLayout now. Maybe that's a better place for
discussion.)

On Monday, 07 July 2003 at 18:58, Ralph Giles wrote:
> 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.

You mean something like (on /trunk)?
/vorbis
/ogg
/bindings
  /vorbis-perl
  /vorbis-python
  /ogg-perl
  /ogg-python

and also
/icecast/libshout
/icecast/bindings
  /shout-perl
  /shout-python

?

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

That's better, but I think it still implies that ices2 supersedes
ices1, which, unfortunately, it doesn't.

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

Ok, I moved these around on the wiki.

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

Ok.

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

I don't think it causes that much clutter. I'm not suggesting creating
a branch at every minor rev (that's what tags are for), so we'd just
have branches for libshout-2.0 vs libshout-2.1 (for example). The idea
is that users know without asking where to get the latest code for a
particular release.

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