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: >> >> On 13 March 2010 10:39, Mark Hindess <mark.hind...@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. > > >
