On 16/03/2010 22:55, Mark Hindess wrote:
In message<3b3f27c61003141715s2a4fa3b4vb5ead378f2f82...@mail.gmail.com>,
Nathan Beyer writes:
On Sun, Mar 14, 2010 at 2:47 AM, Mark Hindess
<mark.hind...@googlemail.com> wrote:
In message<5899fca71003131235w5ae9e96anec0e962aa35e5...@mail.gmail.com>,
Tim Ellison writes:
[snip]
Only to the extent that the whole switching thing makes sense.
Never liked that.
Nor me. I don't like the complexity of it. I particularly don't
like that if you made a connected classlib/drlvm change in java5
trunk you had to do a merge to fix the java6 tree immediately
because the java6 tree uses the java5 drlvm. This used to happen
quite often with common_resources but I've pulled that back into
trunk now so that one is "fixed". (We could fix this by creating a
drlvm java6 branch but then I/we'd have yet another tree to merge.)
Anyway, I guess so, even though it seems a shame to take up so much
unused space.
So why do we keep the "svn switch" structure? If we got rid of the
svn switched layout then we'd have:
trunk/...
trunk/classlib/...
trunk/drlvm/...
trunk/jdktools/...
and:
branches/java6/...
branches/java6/classlib/...
branches/java6/drlvm/...
branches/java6/jdktools/...
Removing the 'svn switch' idiom is fine by me and this suggestion
seems fairly straightforward, so I'm in agreement.
I've thought about this a bit more.
We've a plan (though I'm not sure what progress is being made) to merge
jdktools/branches/java6 back to the jdktools/trunk so we'd have less
branches. This would mean that the java6 branch would only really be
for classlib. And in future, any time we make another branch for one
component, we have to branch everything.
However the duplication of the other components doesn't really cost
anything unless/until changes are made so I don't think this is really
a disadvantage and the reduction in complexity more than makes up for
this.
Unless anyone says otherwise (or says they need more time to think about
downstream processes?), I'd like to push ahead with this next week.
I'll try to figure out the mechanics of changing existing workspaces
without losing changes and I'm happy to fix up the hudson builds if we
go forward with this.
Sounds fine to me. Removing the svn switches will be an improvement to
the federated build IMO and, as you say, this move should remove some of
the merge complexity and make further improvements to the federated
build easier.
Regards,
Oliver
Regards,
Mark.
The only real differences is that we'd have a distinct copy of drlvm
in the java6 branch that we don't currently have but actually that
is arguably an advantage since it breaks the coupling (mentioned
above).
This does mean that you need to do a merge of the whole tree and not
merges of federated build, classlib and jdktools but again I see
this as an advantage not a drawback.
It doesn't stop anyone checking out specific subtrees to work in as
they do now but they'd need to change urls.
It would be quite a painful change but personally I'd be in favour
as it would be a one off change that gets rid of quite a lot of
complexity[0].
Regards,
Mark.
[0] And I've just done the renaming of working_* directories which
was a real nightmare due to all the switches but would have been
much more simple without them.
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
