[Yanel-dev] [Fwd: Development branches in Jackrabbit]

Michael Wechner michael.wechner at wyona.com
Fri May 9 11:45:58 CEST 2008


Maybe something which we can also compare with our code review ideas 
(also see http://subversion.tigris.org/merge-tracking/)

Cheers

Michi

-------- Original Message --------
Subject: 	Development branches in Jackrabbit
Date: 	Fri, 9 May 2008 12:19:31 +0300
From: 	Jukka Zitting <jukka.zitting at gmail.com>
Reply-To: 	dev at jackrabbit.apache.org
To: 	dev at jackrabbit.apache.org



Hi,

We've so far avoided development branches because they might easily
get out of sync with trunk and end up fragmenting development efforts.
I think this is a reasonable strategy, but there are some cases where
short-lived and tightly focused development branches might be a good
idea.

For example in JCR-1579 I refactored the export functionality rather
heavily and I prefer to have people review the changes before
committing them to trunk. However, the aggregate patch is 87kB in size
which makes the changes pretty hard to review. My refactoring
consisted of about a dozen smaller and easier to review steps, which
unfortunately the patch format doesn't convey.

I could have committed those changes directly to trunk and asked for
CTR reviews, but since the changes are pretty extensive I'd rather opt
for a self-imposed RTC review period. One option for better utilizing
our version control infrastructure and avoiding the 87kB patch would
have been to implement the changes in a development branch where I
could have committed each refactoring step separately. People would
have had an easier time reviewing those incremental changes and svn
merge would even have helped handle potential overlapping work by
others.

So, how would you feel if we started using development branches for
such purposes? A development branch would always be tied to a single
focused Jira issue and located at branches/JCR-nnnn. Only changes
related to that issue would be allowed in such a branch, and the
maximum lifetime of such branches would be limited (for example to a
few weeks). The merge tracking feature in svn 1.5 (our svn server is
just being upgraded) could be used to keep the development branches
better in line with trunk and also to handle merging of reviewed
changes back to trunk. Once the issue is resolved and changes merged
to trunk, the development branch would be removed.

BR,

Jukka Zitting


-- 
Michael Wechner
Wyona      -   Open Source Content Management - Yanel, Yulup
http://www.wyona.com
michael.wechner at wyona.com, michi at apache.org
+41 44 272 91 61



More information about the Yanel-development mailing list