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: Branching strategy (Was: svn commit: r601098 - /incubator/river/trunk/jtsk/doc/release-notes/index.html)
Date Fri, 21 Dec 2007 11:46:55 GMT
Hi Jukka, below some explanation,

Jukka Zitting wrote:
> Hi,
> 
> On Dec 17, 2007 1:11 PM, Mark Brouwer <mark.brouwer@cheiron.org> wrote:
>> I like the short notation for the /root/tags/m.n.r but prefer not to mix
>> the sustained development with the /branches which I prefer to keep for
>> whatever ad hoc purpose we need to branch, I also like the short
>> notation for the sustained development.
> 
> What would such ad hoc purposes be?
>
> My advice is not to use "development branches" if there's any way to
> avoid them. Each such branch is essentially a fork of the project.

My experience is that how to implement a feature is often not that
obvious in the first place, also implementing such a feature could be a
cooperative development between a subset of committers that might have
lots of side effects and can take a long time span to materialize before
it can be decided whether the trunk should receive it.

I always created a different branch for such development work as it
allows me to continue on the trunk branch for the smaller more obvious
features. With tools nowadays providing better local versioning I must
admit that this has become less and work against the trunk from a
different workspace, but still when I expect other want to have a look I
create a branch.

You mentioned in the other post that a good practice is never to have
more than a single day of coding effort uncommitted, but my experience
with the Jini codebase is that I will only be able to follow that
practice for the most trivial things, also it ain't my day job most of
the time so for some things I expect to have files (open) for a longer
period of time. I agree when the time span between your branch and the
trunk gets larger in general the merging becomes more painful and that
one should strive to keep it short.

>> I get the feeling that /branches represent what I used to call our
>> /skunk branch (named after skunkworks) where no strict development
>> policies apply and I think that a uniform policy should apply to each
>> branch (besides the /branch branch) and therefore no mix of ad hoc
>> branches with sustained development.
> 
> Could you describe what such branches are used for and how you
> typically use them? I'm a bit worried about how  well this concept
> would work for a distributed development community, but perhaps I'm
> overreacting.

I used skunk branches for all work of which the outcome was not that
obvious or that I expect to take a significant time and for which I want
versioning of object while working on a feature and for which I would
like others to have a look without creating diffs that others have to
apply on some branch. It also allows for other committers to join the
development activity.

The philosophy of truly distributed software development is that each
developer could work in isolation (effectively forks) and later it is
decided what is pushed or pulled into the trunk or between workspaces of
various developers. If my interpretation of Karl Roberts is right this
is the model he proposed, although I think that SVN lack of merge
support makes this too painful.
-- 
Mark


Mime
View raw message