[ZODB-Dev] Subversion repository layout

[Kapil Thangavelu]

On Mon, 2004-04-26 at 15:48, Tim Peters wrote:
> [Jim]
> > The standard subversion repository layout is by project:
> >
> >    proj1
> >         /trunk
> >         /branches
> >                  /br1
> >                  /br2
> >                  ...
> >         /tags
> >              /tag1
> >              /tag2
> >              ...
> 
> ...
> 
> > With this layout, when you want to checkout the main development
> > branch (aka head) of ZODB, you do:
> >
> >    svn co svn+ssh://svn.zope.org/repos/ZODB/trunk ZODB
> >
> > That is, you need to include "/trunk" at the end and provide "ZODB"
> > as the name of the output directory so as not to get a directory named
> > "trunk".  If you forget the "/trunk", you'll get a checkout that
> > includes copies of all of the various tags and branches, which could
> > be huge.
> >
> > I suggest, instead to use the following layout:
> 
> ...
> 
> > Thoughts?
> 
> I read some subversion docs over the weekend, and so am sufficiently
> prepared to live with the oddities of "a standard" subversion layout.  I
> think that if you make a non-standard layout, then everyone coming to, or
> going from, Zope from/to other subversion projects will be forever tripping
> over the uniqueness of Zope's setup.
> 
> IOW, the existing subversion docs cover "the standard" layout quite well.
> If we do something unique, I'm afraid it becomes another piece of folklore
> that will be impossible to guess and difficult to find out about.


i like the layouts jim's presented (specifically #2 of 3), i think when
considering the subversion docs, the important distinctions are made
between the directories used for branches and tags, as long as that
information is clearly communicated the semantics are exactly the same.
the subversion docs themselves outline multiple repository structures
(for example the single project layout), although they do recommend a
standard structure, the docs go through great lengths to convey a
semantic understanding of subversion as a versioned filesystem, not a
magic functional notion as is common with cvs.  i honestly dont think
anyone coming from/to a subversion system will have problems as long as
the location of the trunk, tags, and branches directories for a project
are clearly identifiable.

quoting the svn docs.
"""
Lay out your repository in whatever way you see fit. Subversion does not
expect or enforce a layout schema—in its eyes, a directory is a
directory is a directory. Ultimately, you should choose the repository
arrangement that meets the needs of the people who work on the projects
that live there.
"""

in the existing zopeorg cvs repository, most of the existing projects
are python packages, multiples of which must be stitched together to
make a working dev environment, using jim's layout avoids alot of
needless renaming.

on the flipside, it only avoids the renaming in the case of using the
trunk, and while they are the only things being converted at the moment,
from my experience most of the checkouts from zopeorg have been on
release branches, afaik, and i believe jim wanted to continue with
existing structure such that most of the toplevel projects are not
python packages. so the benefits/comparative advantage aren't that
strong in this case in terms of breaking with the common expectation of
repository layout.

two cents,

-kapil