harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <ndbe...@apache.org>
Subject Re: svn layout (was Re: Build failed in Hudson: ...)
Date Mon, 15 Mar 2010 00:15:22 GMT
On Sun, Mar 14, 2010 at 2:47 AM, Mark Hindess
<mark.hindess@googlemail.com> wrote:
>
> In message <5899fca71003131235w5ae9e96anec0e962aa35e5f00@mail.gmail.com>,
> Tim Ellison writes:
>>
>> On 13 March 2010 10:39, Mark Hindess <mark.hindess@googlemail.com> wrote:
>> >
>> > These build breaks were caused by my common_resources change.  I've
>> > fixed that (by removing the reference to the old common_resources
>> > checkout) but it highlights another problem.
>> >
>> > This hudson build can't create a correct workspace if the workspace
>> > is deleted.  The reason is that it checks out the federated build to
>> > harmony thus creating harmony/ working_classlib but this is not yet
>> > "svn switch"ed to the real classlib tree.  Then it tries to check
>> > out harmony/working_classlib with the real url but sees the already
>> > svn checked out directory and refuses to overwrite it.
>> >
>> > The fix is to manually visit the workspace and "svn switch
>> > working_*" to the appropriate urls.  I've done this for now.
>> >
>> > I think the only way to fix this and track the svn commits
>> > is to checkout the working_* trees to, for example,
>> > ignored/working_classlib and suffer the duplication.
>> >
>> > Tim, does that make sense?  I don't think we can have builds that
>> > can't bootstrap their own workspace.
>>
>> 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.

>
> 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.
>
>
>

Mime
View raw message