Tim Peters wrote:

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 don't know much about subversion, but this strikes me as a good argument for sticking with the standard layout. Regards, Martijn

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

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

On Tue, 2004-04-27 at 10:27, Martijn Faassen wrote:

Kapil Thangavelu wrote:

...

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.

I tried to understand this sentence a few, but I don't get it yet.

So, are you saying you think we *shouldn't* use a custom layout and thus stick with the 'default' svn layout, or are you saying you think we should deviate from the default svn layout?

i'm saying we should probably stick with the default layout. why? because the primary benefit of the alternative layout is to avoid having to do a rename while checking out the trunk of a project, on checking out from branches or tags, this is required anyways. and in my experience most of the checkouts will likely be on release branches, and tags anyways. iotw. its of little benefit considering the disadvantages of moving from the default layout. cheers, -kapil