river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: svn commit: r601098 - /incubator/river/trunk/jtsk/doc/release-notes/index.html
Date Mon, 10 Dec 2007 11:09:16 GMT
Hi Karl, thanks for chipping in. As said I'm a SVN virgin, although I
read the SVN book quickly a while ago it is certainly possible my 
reasoning is crippled by the difficulties of implementing it in SVN.

karl.j.roberts@jpmorgan.com wrote:
> Hi Guys, 
> 
> Re the branching "lifecycle", I think that the life of a branch should be 
> short,  if possible branches should only be used to do one thing, ie add a 
> feature, or re-implement a component, and try not to wander off into a 
> myriad of different tweaks.

If you mean with 'branch' in the above the work conducted in the
/branches/ I agree, but my experience is that there are branches other
than /trunk that have a long lifespan, namely the maintenance branches.
this is both my experience in open source projects and supporting
commercial products. Unfortunately not all customers want to work with
the latest release and often you have to provide fixes and backport
features for releases you would like, from a development perspective, to
see retired.

> I'd like to see the Trunk be the latest (tested) working code, with 
> branches used to develop features.
> Tags from Trunk to highlight stable releases of feature sets.
> possibly a BugFix Branch per feature-set Tag.

I think this should be based on an analysis of the codebase touched by
the features or bug-fix to be implemented. There are many features and
fixes that only touch one file, have no overlap with other planned work
and for which I consider the overhead of branching, merging and creating
a new workspace too much. Call it the rather trivial stuff (such as
plenty of typos scheduled for AR2), and I realize that there is a gray
area what to call trivial.

Even if branching is cheap as many SCM tools advertise the work that
comes from branching and integration isn't. Currently there is a small
team around the Jini codebase who can commit in SVN and I hope that with
proper communication we can prevent from the need for a truly
distributed SCM tool.

I really hope that if work for fixes, features touches the same
versioned objects that communication can arrange for people working on
features in sequence. If that is not possible than I hope we communicate
about who is responsible for integrating the 2 branches. Too many times
I've seen that people rushed to the gate and leave the painful
integration to others.

> I think that a naming convention for tags is a must, and that we should 
> map branches and the features that they are adding in a "roadmap" 
> document, so people can easily see what is being developed where.

Yes, I think it is a good idea to put that kind of information in the
roadmap, at least as part of the JIRA issue.

> Also because subversion merging of branches is not straightforward (you 
> need to know the version number when you branched, not just the head of 
> your branch) then a published Merge procedure, and preferably a dedicated 
> "merger" role, with people who have good experience at merging svn doing 
> the merge to trunk.

This worries me a bit. In case we branch like rabbits :-) and the tool
has little support for integration of branches for which the versioned
objects evolve and get further from their branch point I foresee a lot
of overhead to get stuff back to the trunk. I'm still trying to
understand why practices should differ from best practices with Perforce
which has a similar model, albeit better support for integration of
branches, and their best practices suggest to branch as little as possible.

If it is really necessary one should work in its own branch, version
from there and be able to share its work with other for each and every
task then I think we should be looking for a tool that supports that
kind of workflow ... fill in a truly distributed SCM. But still that
doesn't takes a way the pain of integration and as doctors say
'prevention is better than cure'.
-- 
Mark



Mime
View raw message