Re: svn layout

[Mark Hindess <ma...@googlemail.com>]

In message <3b...@mail.gmail.com>,
Nathan Beyer writes:
>
> On Sun, Mar 14, 2010 at 2:47 AM, Mark Hindess
> <ma...@googlemail.com> wrote:
> >
> > In message <58...@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.

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.

Re: svn layout

[Oliver Deakin <ol...@googlemail.com>]

On 16/03/2010 22:55, Mark Hindess wrote:
> In message<3b...@mail.gmail.com>,
> Nathan Beyer writes:
>    
>> On Sun, Mar 14, 2010 at 2:47 AM, Mark Hindess
>> <ma...@googlemail.com>  wrote:
>>      
>>> In message<58...@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