This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: libgcj-classpath-20060719 merge
- From: Tom Tromey <tromey at redhat dot com>
- To: Haren Visavadia <themis_hv at yahoo dot co dot uk>
- Cc: Tom Tromey <tromey at redhat dot com>, Mark Wielaard <mark at klomp dot org>, Thomas Fitzsimmons <fitzsim at redhat dot com>, java at gcc dot gnu dot org, Andreas Tobler <toa at pop dot agri dot ch>
- Date: Mon, 31 Jul 2006 14:09:46 -0600
- Subject: Re: libgcj-classpath-20060719 merge
- References: <17614.13773.339037.630628@localhost.localdomain> <20060731200502.99595.qmail@web25703.mail.ukl.yahoo.com>
- Reply-to: tromey at redhat dot com
>>>>> "Haren" == Haren Visavadia <themis_hv@yahoo.co.uk> writes:
>> It seems weird that in order to do a merge we must create a third
>> branch.
Haren> It makes it into more logical steps:
Haren> classpath -> gcj-classpath-integration -> trunk
I don't agree that it is more logical. I think that doing a merge and
then fixing it to build correctly is a "normal" operation, one which
ought not require an intermediate staging branch in order to get a
good diff.
That said I don't think it is substantially "less logical" to get
diffs against the merge-ee base revision. It is weird for me, and I
can't really imagine why you'd ever want this, but I'm assuming this
is just an imagination failure on my part.
Haren> 1. Can depend on svn to generate the perfect diff
My contention is that svn ought to be able to create a perfect diff
already, without requiring a 3rd branch.
Haren> 8. No surpises or mysteries
This can hardly be claimed to be a benefit when the surprises and
mysteries are svn-induced themselves :-)
Anyway, we're stuck with what we've got.
Tom