Repository procedure proposal

[Noah Slater <ns...@bytesexual.org>]

Hey,

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

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:

  releases/0.8

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. ;)

Thanks,

--
Noah Slater <http://bytesexual.org/>

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.

Re: Repository procedure proposal

[Damien Katz <da...@gmail.com>]

I think I agree with Jan. At this point in the project, while the  
code is still young, most work should go into the trunk. I think the  
trunk should be in working condition, but considered unstable for  
deployment. To keep things moving forward, most new code should go  
into the trunk.

Therefore branches will be created when we want a stable code stream  
(releases), or when we are working on disruptive changes (ex.  
mochiweb), but generally all new work should go into the trunk.

Later in the project, as project and code base and contributors get  
bigger, we may need to switch to a more structured system, but for  
now I think a single, slightly unstable trunk with occasional  
branches is the most efficient way.

-Damien

On Feb 29, 2008, at 9:06 AM, Jan Lehnardt wrote:

> Heya,
> On Feb 29, 2008, at 13:53, Noah Slater wrote:
>> Toughts, comments, ridicule? All welcome. ;)
>
> Let's not do that :)
>
> Having trunk representing the latest release only seems
> to me as arbitrarily diverting from the route people are
> used to: Trunk is where development happens and where
> it can be messy. Stable branches are where people can go
> an pick stable releases if trunk is unusable for the moment.
> Which I hope doesn't happen too often, but still.
>
> Experimental work, like the mochiweb, should still happen
> in separate branches. Releases get their on branches for
> maintenance.
>
> Your argument that ChangeLog remains clean assumes that
> we have automatic ChangeLog generation. This is fine per se,
> but a little change to the mechanism would solve the problem
> of ChangeLog pollution.
>
> The automatic generation would take SVN commit messages
> and put them into the ChangeLog automatically. If we do a lot
> of minor changes and reverts and whatnot, the ChangeLog
> grows unnecessarily and contains entries of little value.
>
> Instead of copying every message, our automaton could look
> for opt-out tags in the message. For example a message
> prepended with a "!" (Bang) denominates a small change,
> like a revert, and ignores it for the creation of The ChangeLog.
>
> If the opt-out tag is forgotten, we still end up with too many
> entries, but we can go through the ChangeLog before a
> release. We might do that anyway for preparing a release
> announcement.
>
> Cheers
> Jan
> --

Re: Repository procedure proposal

[Jan Lehnardt <ja...@googlemail.com>]

Heya,
On Feb 29, 2008, at 13:53, Noah Slater wrote:
> Toughts, comments, ridicule? All welcome. ;)

Let's not do that :)

Having trunk representing the latest release only seems
to me as arbitrarily diverting from the route people are
used to: Trunk is where development happens and where
it can be messy. Stable branches are where people can go
an pick stable releases if trunk is unusable for the moment.
Which I hope doesn't happen too often, but still.

Experimental work, like the mochiweb, should still happen
in separate branches. Releases get their on branches for
maintenance.

Your argument that ChangeLog remains clean assumes that
we have automatic ChangeLog generation. This is fine per se,
but a little change to the mechanism would solve the problem
of ChangeLog pollution.

The automatic generation would take SVN commit messages
and put them into the ChangeLog automatically. If we do a lot
of minor changes and reverts and whatnot, the ChangeLog
grows unnecessarily and contains entries of little value.

Instead of copying every message, our automaton could look
for opt-out tags in the message. For example a message
prepended with a "!" (Bang) denominates a small change,
like a revert, and ignores it for the creation of The ChangeLog.

If the opt-out tag is forgotten, we still end up with too many
entries, but we can go through the ChangeLog before a
release. We might do that anyway for preparing a release
announcement.

Cheers
Jan
--

Re: Repository procedure proposal

[Kerr Rainey <ke...@rokera.com>]

On Fri, Feb 29, 2008 at 12:53 PM, 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.

Just to put another suggestion on the table,  I quite like the
stratagy where all main work is done in trunk and then branches are
pulled to finalise work for a release, merging appropriate changes
back into trunk.  The realses then happens from the branch.

Put, you know, I'm not that bothered, so whatever makes sense for the
people doing most of the svn admin.

--
Kerr