svn layout (was Re: Build failed in Hudson: ...)

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