jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Development branches in Jackrabbit
Date Fri, 09 May 2008 12:11:16 GMT
Hi

in general I'm +1 on using development branches, however I would rather use the 
sandbox for that and strictly limit the use to larger refactorings.

regards
  marcel

Jukka Zitting wrote:
> 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
> 


Mime
View raw message