harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][general]Sync casslib trunk and Java 6 branch
Date Mon, 04 Jun 2007 09:24:29 GMT
Yang Paulex wrote:
> Hi, All
> I'd like to start to look at classlib in Java 6 recently, before committing
> anything, I wanted to discuss sync issue at first. There are several issues
> here:
> 1. How to sync trunk(Java 5) and Java 6 branch
> Merge from trunk to Java 6 branch is necessary, because the Java 5 work is
> still in progress, so most bug fixing work makes senses for Java 6 branch.
> On the other hand, from Java 6 branch to trunk is not necessary. "svn
> merge"

I agree, merging in one direction makes sense, and people should fix the
bug in the 5.0 stream if it is relevant to both.

> can help a lot here, some other decentralized version control system like
> svk[1] may be more powerful, but I'd propose we start from basic  tool here
> to see if everything is OK.

I have no objection to doing it manually a few times, with a view to
automating it once it becomes repetitive.

> I'd propose the steps below to merge it:
> cd <java 6 working copy>
> svn merge -r
> https://svn.apache.org/repos/asf/harmony/enhanced/classlib/tags/latest-merge
> https://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk@<REVISION>
> <resolve conflict if there are some>
> ant build
> ant test
> <verify everything is OK>
> svn commit -m "merge from trunk@REVISION to java 6 branch"
> svn copy -r REVISION
> https://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk
> https://svn.apache.org/repos/asf/harmony/enhanced/classlib/tags/latest-merge
> One SVN tag - latest-merge - needs to be created as a snapshot of trunk
> merged last time, so that committer doesn't need to record the revision
> number every time.
> 2. How frequently should the merge be performed?
> I'd like to say "as frequent as possible", but the effort is too much.
> Maybe
> daily merge is a reasonable trade-off.

Daily sounds pretty frequent to me, again it depends upon how well
automated the merge is, so we can try it and see.  Of course, the
advantage of a frequent merge is that there is less work to merge in, so
little and often is probably a good idea.  There will be some
exceptions, like the incoming bulk contributions that may be more

> 3. Should this be automatically?
> Sure, although some kind of manually work is unavoidable when conflicts
> happen.  But I'd like to try it for several times until we are sure it's
> safe to make it automatically.
> I'm volunteer to perform the daily merge before that if no one objects.

Thanks for volunteering to start this.


> Your comments are highly appreciated.
> [1] http://svk.bestpractical.com/view/HomePage, a decentralized
> <http://en.wikipedia.org/wiki/Version_control_system>version control system
> written in Perl based on SVN, with a design comparable BitKeeper and Git

View raw message