You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2010/03/13 11:39:36 UTC
Re: Build failed in Hudson: Harmony-1.5-head-linux-x86_64 #696
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.
Regards,
Mark.
In message <14...@hudson.zones.apache.org>,
Apache Hudson Server writes:
>
> See <http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/696/>
>
> ------------------------------------------
> Started by user hindessm
> Building remotely on minerva.apache.org (Ubuntu)
> Checking out a fresh workspace because the workspace is not http://svn.apache
> .org/repos/asf/harmony/enhanced/classlib/trunk
> Checking out http://svn.apache.org/repos/asf/harmony/enhanced/trunk
> AU NOTICE
> [snip]
> ERROR: Failed to check out http://svn.apache.org/repos/asf/harmony/enhanced/c
> lasslib/trunk
> org.tmatesoft.svn.core.SVNException: svn: '<http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/ws/harmony/working_classlib'> is already a working copy for a different URL
Re: Build failed in Hudson: Harmony-1.5-head-linux-x86_64 #696
Posted by Mark Hindess <ma...@googlemail.com>.
In message <58...@mail.gmail.com>,
Tim Ellison writes:
>
> On 13 March 2010 10:39, Mark Hindess <ma...@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.
Let's discuss that.
> Anyway, I guess so, even though it seems a shame to take up so much
> unused space.
I've modified the builds to use 'ignored'. Some were already using
'harmony/ignored' so I used that prefix although actually I think having
them outside the harmony tree might be more straightforward.
I also fixed the 'Harmony-1.5-head-linux-x86_64-full-tests' as this was
missing a call to populate-src so it couldn't bootstrap itself from a
wiped workspace either.
Regards,
Mark.
svn layout (was Re: Build failed in Hudson: ...)
Posted by Mark Hindess <ma...@googlemail.com>.
In message <58...@mail.gmail.com>,
Tim Ellison writes:
>
> On 13 March 2010 10:39, Mark Hindess <ma...@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/...
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
Posted by 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
Re: svn layout
Posted by 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 (was Re: Build failed in Hudson: ...)
Posted by Nathan Beyer <nd...@apache.org>.
On Sun, Mar 14, 2010 at 2:47 AM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> In message <58...@mail.gmail.com>,
> Tim Ellison writes:
>>
>> On 13 March 2010 10:39, Mark Hindess <ma...@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.
>
>
>
Re: Build failed in Hudson: Harmony-1.5-head-linux-x86_64 #696
Posted by Tim Ellison <t....@gmail.com>.
On 13 March 2010 10:39, Mark Hindess <ma...@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.
Anyway, I guess so, even though it seems a shame to take up so much
unused space.
Regards,
Tim