[ZODB-Dev] Subversion repository layout

[Kapil Thangavelu]

On Mon, 2004-04-26 at 22:30, Tim Peters wrote:
> [Kapil Thangavelu]
> > ...
> > 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),
> 
> Sorry, I haven't seen that.  The "Choosing a Repository Layout" section does
> talk about many ways to organize repositories, like multiple repositories vs
> one, and putting all projects in a repository at top level vs grouping them
> into "related" subtrees.  But in all these cases, the only structure for a
> project they discuss or illustrate has project/trunk, project/branches, and
> project/tags structure.

there are numerous references throughout the docs to alternative
repository structures, like having one with

/trunk/projectname
http://svnbook.red-bean.com/svnbook/ch03s06.html

or several examples w/ pics without trunk, tag, branches at all, 
http://svnbook.red-bean.com/svnbook/ch02s03.html

but regardless its true that the vast majority of the examples assume
the 
/projectname/trunk
            /branches

setup. 

> 
> > 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.
> 
> I haven't used svn, and I'm more concerned about people like me <wink>:  the
> docs assume a specific project (not repository) layout throughout.  I'm not
> interested in svn for its own sake, it's just something I'll need to do my
> job.  The closer the docs match the system I have to work with, the easier
> it will be to get started.

imo, the docs dont assume one layout, they have mixed examples, with a
majority of them given with suggested layout, reading past the
copy/paste code though and i think it tries to make clear numerous times
that its not about the layout its about the semantics and policy
assigned to locations.

for example here's a quote on creating branches

"""
Creating a branch is very simple—you make a copy of the project in the
repository using the svn copy command. Subversion is not only able to
copy single files, but whole directories as well. In this case, you want
to make a copy of the /calc/trunk directory. Where should the new copy
live? Wherever you wish—it's a matter of project policy. Let's say that
your team has a policy of creating branches in the /calc/branches area
of the repository, and you want to name your branch my-calc-branch.
You'll want to create a new directory, /calc/branches/my-calc-branch,
which begins its life as a copy of /calc/trunk. 
"""



> 
> I can't say Jim's suggestions are bad, or good -- I can't judge them since I
> haven't used svn (you?).  Going against the recommendation of the people who
> designed and coded the system seems a dubious step on the face of it,
> though.

i've been using svn for almost 2yrs, for client projects the last year,
and i'm about to convert over plone and the sf.net collective project
(~150 Products) and around 200 committers over to svn. i think jim's
proposed layout could be very helpful there, as typically people will be
using unfamiliar gui clients (like tortoisesvn) and will be checking out
the head of the products and nitting them together to create a working
zope instance/dev enviornment, in which case avoiding having to fillin
an extra dialog might be nice and pratical. but i'm going to try and
solicit feedback on those project lists.


> 
> > 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.
> > """
> 
> That's at the end of the "Choosing a Repository Layout" section.  As above,
> that section discusses and shows nothing but "the standard" per-project
> layout; the layout choices they do discuss in that section are the ones
> mentioned above (how to organize projects in relation to each other, and in
> relation to repositories).
> 

it does shows another layout in the choosing repository layout scheme
section, namely the single project etc, which you could say jim's layout
is adapted from.. ie.
/trunk
/branches
/tags

sigh.. debating over what the book says isn't very productive.  my
conclusions at the end of my previous email, namely that what this
layout will accomplish for the zopeorg repository in terms of avoiding
renames of checkouts will likely be fairly limited in pratice, still win
me out against deviating from the standard layouts.

cheers,

-kapil