couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Savory" <>
Subject Re: Repository procedure proposal
Date Mon, 03 Mar 2008 09:17:48 GMT
On 29/02/2008, Noah Slater <> wrote:

> I would like to make a very rough suggestion for how we lay out and manage
> our
> Subversion repository on and after the code drop.
> I propose that we have the following top level directories:
>   branches
>   releases
>   site
>   tags
>   trunk
>   vendor

... releases are just specifically-named tags, usually.

You might want to do something like tags/couchdb-1.0
/RELEASE_1, tags/couchdb-1.0/RELEASE_1_1, tags/couchdb-2.0/RELEASE_2 etc.

> As it stands we have trunk where most of the changes take place. This
> results in
> a trunk which breaks occasionally (often due to my own checkins) and
> acrues a
> great number of tiny changes, hacks and reverts. This makes it more risky
> than
> it should be to pull a stable version from the source and bloats the
> ChangeLog.

'trunk' is by most definitions usually the bleeding edge and subject to

Changelogs (as others have mentioned) can be handled a number of ways. I'm a
fan of using JIRA for enumerating the major changes, but YMMV.

Thoughts, comments, ridicule? All welcome. ;)

I'm always interested to hear new ideas, but this seems over-complicated to
me, and rather counter-intuitive to most other open source svn-based

But hey, copies, branches etc are cheap in svn, so we could always start
with something simple like tags/ trunk/ branches/ site/ and modify it later?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message