Hi, On 29/02/2008, Noah Slater <[EMAIL PROTECTED]> 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.
