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