Re: Repository procedure proposal

[Andrew Savory <sa...@andrewsavory.com>]

Hi,
On 29/02/2008, Noah Slater <ns...@bytesexual.org> 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
breaking.

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
projects.

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?



Andrew.