couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Repository procedure proposal
Date Fri, 29 Feb 2008 12:53:26 GMT

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:


The names/hierarchy are maleable and not important for what I'm proposing.

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.

I would like to propose that trunk always reflects the last official release
with an archive of releases being kept under tags as per convention.

Each time a release is made we copy the trunk into releases using the minor
version number as a directory name. Here is an example:

 1) Check in final changes to trunk and release version 0.8.0.
 2) Copy trunk to tags/0.8.0
 2) Copy trunk to releases/0.8

Then, all non-branch work (large projects like mochiweb) takes place in:


When we are ready to make the 0.8.1 release we follow this procedure:

  1) Merge back changes from releases/0.8 to trunk
  2) Release version 0.8.1.
  3) Copy trunk to tags/0.8.1

Then, work continues to take place in releases/0.8 until we're ready to:

  1) Merge back changes from releases/0.8 to trunk
  2) Release version 0.8.2.
  3) Copy trunk to tags/0.8.2

Once we're ready to move to version 0.9 we copy trunk to releases/0.9.

The idea would be that the releases directory would fill up with X.Y directories
for every minor version of the software which should make it nice and easy to
release bug fixes for legacy versions etc.

Branching would work like normal but the branches would be cut from the
appropriate release directory instead of trunk and merged back prior to a final
merge back to trunk for the release.

This is just a rough sketch, there's probably stuff I haven't considered.

Thoughts, comments, ridicule? All welcome. ;)


Noah Slater <>

View raw message