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 2008/02/06 11:02:23 UTC
Breaking the build again (was Re: [announce] new DRLVM build system
came into force)
I was hoping Alexey might comment on this given his involvement in the
changes but I think it is a good idea to "fix" this now. Unless anyone
complains I will take a look at doing it tomorrow.
This will break builds and people will need to "svn switch" their
commond_resources tree (or remove it and re-populate it if you have
infinite bandwidth).
Regards,
Mark.
------- Forwarded Message
From: Mark Hindess <ma...@googlemail.com>
To: dev@harmony.apache.org
Subject: Re: [announce] new DRLVM build system came into force
Date: Tue, 05 Feb 2008 09:20:50 +0000
Excellent!
Before we get too comfortable with the changes we might want to think
about whether:
https://svn.apache.org/repos/asf/harmony/enhanced/common_resources
should really be moved to:
https://svn.apache.org/repos/asf/harmony/enhanced/common_resources/trunk
We are going to want to be able to reproduce build so having the
capability to use branches and tags might be useful. And it would
be more consistent with the layout of the other svn-switched
sub-directories of the federated build.
I'll take a look at moving the dependencies in classlib to common_resources
but before I force everyone working on classlib to checkout common_resources
I'd like to get this resolved so we don't end up breaking it later.
- -Mark.
On 4 February 2008 at 16:51, "Alexey Varlamov" <al...@gmail.com>
wrote:
> Folks,
>
> The new build system for DRLVM is now the offical one, our integrity
> and snapshot CC systems were switched to it before this weekend.
> Currently there is certain duplication of resources between the new
> and old systems (property files, etc); I suggest we drop the old
> system in a week or two.
> Also, the old build directory encloses x-lists and MSVC solutions.
> X-lists apparently should be moved closer to test sources, but what
> about the solutions - just move them to working_vm/make? AFAIU they
> need update to changed deploy dir names, any volunteers?
> Meanwhile please be careful to update the right files, those in
> <working_vm>/make tree.
> I've updated GettingStarted page to reflect build changes, and will
> update README.txt soon. Hopefully the transition to unified build
> interface will be smooth for DRLVM developers.
>
> --
> Alexey
>
------- End of Forwarded Message
Re: Breaking the build again (was Re: [announce] new DRLVM build
system came into force)
Posted by Tim Ellison <t....@gmail.com>.
Mark Hindess wrote:
> I was hoping Alexey might comment on this given his involvement in the
> changes but I think it is a good idea to "fix" this now. Unless anyone
> complains I will take a look at doing it tomorrow.
>
> This will break builds and people will need to "svn switch" their
> commond_resources tree (or remove it and re-populate it if you have
> infinite bandwidth).
If you do intend to do it soon, please do it soon :-) so that we have a
chance to update build systems etc well before entering the M5 stability
period. i.e. tomorrow would be better than next week.
Regards,
Tim
Re: Breaking the build again (was Re: [announce] new DRLVM build system came into force)
Posted by Alexey Varlamov <al...@gmail.com>.
Mark,
I support this move, apparently common build should follow general
structure for smooth branching. I thought about it myself but inclined
to postpone until real demand appeared.
--
Alexey
2008/2/6, Mark Hindess <ma...@googlemail.com>:
>
> I was hoping Alexey might comment on this given his involvement in the
> changes but I think it is a good idea to "fix" this now. Unless anyone
> complains I will take a look at doing it tomorrow.
>
> This will break builds and people will need to "svn switch" their
> commond_resources tree (or remove it and re-populate it if you have
> infinite bandwidth).
>
> Regards,
> Mark.
>
> ------- Forwarded Message
>
> From: Mark Hindess <ma...@googlemail.com>
> To: dev@harmony.apache.org
> Subject: Re: [announce] new DRLVM build system came into force
> Date: Tue, 05 Feb 2008 09:20:50 +0000
>
> Excellent!
>
> Before we get too comfortable with the changes we might want to think
> about whether:
>
> https://svn.apache.org/repos/asf/harmony/enhanced/common_resources
>
> should really be moved to:
>
> https://svn.apache.org/repos/asf/harmony/enhanced/common_resources/trunk
>
> We are going to want to be able to reproduce build so having the
> capability to use branches and tags might be useful. And it would
> be more consistent with the layout of the other svn-switched
> sub-directories of the federated build.
>
> I'll take a look at moving the dependencies in classlib to common_resources
> but before I force everyone working on classlib to checkout common_resources
> I'd like to get this resolved so we don't end up breaking it later.
>
> - -Mark.
>
> On 4 February 2008 at 16:51, "Alexey Varlamov" <al...@gmail.com>
> wrote:
> > Folks,
> >
> > The new build system for DRLVM is now the offical one, our integrity
> > and snapshot CC systems were switched to it before this weekend.
> > Currently there is certain duplication of resources between the new
> > and old systems (property files, etc); I suggest we drop the old
> > system in a week or two.
> > Also, the old build directory encloses x-lists and MSVC solutions.
> > X-lists apparently should be moved closer to test sources, but what
> > about the solutions - just move them to working_vm/make? AFAIU they
> > need update to changed deploy dir names, any volunteers?
> > Meanwhile please be careful to update the right files, those in
> > <working_vm>/make tree.
> > I've updated GettingStarted page to reflect build changes, and will
> > update README.txt soon. Hopefully the transition to unified build
> > interface will be smooth for DRLVM developers.
> >
> > --
> > Alexey
> >
>
>
> ------- End of Forwarded Message
>
>
>
>
>
>
Re: Breaking the build again (was Re: [announce] new DRLVM build
system came into force)
Posted by Mark Hindess <ma...@googlemail.com>.
I've made this change at r619373. The federation build.xml has also
been updated and the transition here is smooth. (Although you get
branches, tags, and trunk in common_resources when you update, the
svn_switch fixes this when you run ant.)
If you have other copies of common_resources checked out you should run
update and run svn switch to fix them. For example:
bash$ svn info |awk '/URL/ { print $2 }'
https://svn.apache.org/repos/asf/harmony/enhanced/common_resources
bash$ svn up
...
bash$ svn switch \
https://svn.apache.org/repos/asf/harmony/enhanced/common_resources/trunk
Alexey, I agree with Tim. The semantics of svn:externals aren't really
suitable for branching and tagging.
Regards,
Mark.
On 6 February 2008 at 10:02, Mark Hindess <ma...@googlemail.com> wrote:
>
> I was hoping Alexey might comment on this given his involvement in the
> changes but I think it is a good idea to "fix" this now. Unless anyone
> complains I will take a look at doing it tomorrow.
>
> This will break builds and people will need to "svn switch" their
> commond_resources tree (or remove it and re-populate it if you have
> infinite bandwidth).
>
> Regards,
> Mark.
>
> ------- Forwarded Message
>
> From: Mark Hindess <ma...@googlemail.com>
> To: dev@harmony.apache.org
> Subject: Re: [announce] new DRLVM build system came into force
> Date: Tue, 05 Feb 2008 09:20:50 +0000
>
> Excellent!
>
> Before we get too comfortable with the changes we might want to think
> about whether:
>
> https://svn.apache.org/repos/asf/harmony/enhanced/common_resources
>
> should really be moved to:
>
> https://svn.apache.org/repos/asf/harmony/enhanced/common_resources/trunk
>
> We are going to want to be able to reproduce build so having the
> capability to use branches and tags might be useful. And it would
> be more consistent with the layout of the other svn-switched
> sub-directories of the federated build.
>
> I'll take a look at moving the dependencies in classlib to common_resources
> but before I force everyone working on classlib to checkout common_resources
> I'd like to get this resolved so we don't end up breaking it later.
>
> - -Mark.
>
> On 4 February 2008 at 16:51, "Alexey Varlamov" <al...@gmail.com>
> wrote:
> > Folks,
> >
> > The new build system for DRLVM is now the offical one, our integrity
> > and snapshot CC systems were switched to it before this weekend.
> > Currently there is certain duplication of resources between the new
> > and old systems (property files, etc); I suggest we drop the old
> > system in a week or two.
> > Also, the old build directory encloses x-lists and MSVC solutions.
> > X-lists apparently should be moved closer to test sources, but what
> > about the solutions - just move them to working_vm/make? AFAIU they
> > need update to changed deploy dir names, any volunteers?
> > Meanwhile please be careful to update the right files, those in
> > <working_vm>/make tree.
> > I've updated GettingStarted page to reflect build changes, and will
> > update README.txt soon. Hopefully the transition to unified build
> > interface will be smooth for DRLVM developers.
> >
> > --
> > Alexey
> >
>
>
> ------- End of Forwarded Message
>
>
>
>
Re: Breaking the build again (was Re: [announce] new DRLVM build system came into force)
Posted by Alexey Varlamov <al...@gmail.com>.
2008/2/7, Tim Ellison <t....@gmail.com>:
> Alexey Varlamov wrote:
> >> I have a natural aversion to svn:externals since it messes up the SVN
> >> version control. When you copy a resource with an externals property to
> >> a new branch, the branch has a copy of the property (not what it points
> >> to). This makes it too easy to modify the HEAD when you think you are
> >> working on a branch, and makes the branch mutable from the HEAD.
> >
> > The SVN manual covers this issue; they say "commit" command
> > specifically ignores external subdirectories unless they are
> > explicitly pointed.
>
> Right, but unless you know you are in an externals subdirectory it is
> too easy to, say, cd into the java 6 branch class lib concurrent module
> standard directory and make a change that gets picked up by the java 5
> branch. We know about that case, but if there are a lot of externals
> pointing around the place you can miss these hidden dependencies.
Using HTTP protocol should be good enough preventive measure for us.
BTW I recall Chris complained once that he had troubles checking out
HTTPS-based externals in a HTTP-based workspace, I think we should fix
this.
>
> > BTW similar issue may happen in a "mixed" workspace with
> > subdirectories switched to different branches.
>
> Yes, and for the same reason I would also be unhappy if we switched at
> levels below the working_* directories. It just gets too hard to manage
> multiple branches of the code.
>
> Regards,
> Tim
>
>
Re: Breaking the build again (was Re: [announce] new DRLVM build
system came into force)
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
>> I have a natural aversion to svn:externals since it messes up the SVN
>> version control. When you copy a resource with an externals property to
>> a new branch, the branch has a copy of the property (not what it points
>> to). This makes it too easy to modify the HEAD when you think you are
>> working on a branch, and makes the branch mutable from the HEAD.
>
> The SVN manual covers this issue; they say "commit" command
> specifically ignores external subdirectories unless they are
> explicitly pointed.
Right, but unless you know you are in an externals subdirectory it is
too easy to, say, cd into the java 6 branch class lib concurrent module
standard directory and make a change that gets picked up by the java 5
branch. We know about that case, but if there are a lot of externals
pointing around the place you can miss these hidden dependencies.
> BTW similar issue may happen in a "mixed" workspace with
> subdirectories switched to different branches.
Yes, and for the same reason I would also be unhappy if we switched at
levels below the working_* directories. It just gets too hard to manage
multiple branches of the code.
Regards,
Tim
Re: Breaking the build again (was Re: [announce] new DRLVM build system came into force)
Posted by Alexey Varlamov <al...@gmail.com>.
> I have a natural aversion to svn:externals since it messes up the SVN
> version control. When you copy a resource with an externals property to
> a new branch, the branch has a copy of the property (not what it points
> to). This makes it too easy to modify the HEAD when you think you are
> working on a branch, and makes the branch mutable from the HEAD.
The SVN manual covers this issue; they say "commit" command
specifically ignores external subdirectories unless they are
explicitly pointed.
BTW similar issue may happen in a "mixed" workspace with
subdirectories switched to different branches.
--
Alexey
>
> Regards,
> Tim
>
Re: Breaking the build again (was Re: [announce] new DRLVM build
system came into force)
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> Sorry, here is somewhat belated recollection: it makes sense to modify
> the federated structure a bit further and make common_resources
> plugged as svn:externals rather than svn-switch it. This way we'd have
> the same versioning abilities plus can benefit reusing same
> properties.xml, svn info utilities, etc in the federated build.xml via
> direct import.
> If you did not yet finish with this, it is a good time to include the
> above change as well.
I have a natural aversion to svn:externals since it messes up the SVN
version control. When you copy a resource with an externals property to
a new branch, the branch has a copy of the property (not what it points
to). This makes it too easy to modify the HEAD when you think you are
working on a branch, and makes the branch mutable from the HEAD.
Regards,
Tim
Re: Breaking the build again (was Re: [announce] new DRLVM build system came into force)
Posted by Alexey Varlamov <al...@gmail.com>.
2008/2/6, Mark Hindess <ma...@googlemail.com>:
>
> I was hoping Alexey might comment on this given his involvement in the
> changes but I think it is a good idea to "fix" this now. Unless anyone
> complains I will take a look at doing it tomorrow.
>
> This will break builds and people will need to "svn switch" their
> commond_resources tree (or remove it and re-populate it if you have
> infinite bandwidth).
>
> Regards,
> Mark.
>
> ------- Forwarded Message
>
> From: Mark Hindess <ma...@googlemail.com>
> To: dev@harmony.apache.org
> Subject: Re: [announce] new DRLVM build system came into force
> Date: Tue, 05 Feb 2008 09:20:50 +0000
>
> Excellent!
>
> Before we get too comfortable with the changes we might want to think
> about whether:
>
> https://svn.apache.org/repos/asf/harmony/enhanced/common_resources
>
> should really be moved to:
>
> https://svn.apache.org/repos/asf/harmony/enhanced/common_resources/trunk
>
> We are going to want to be able to reproduce build so having the
> capability to use branches and tags might be useful. And it would
> be more consistent with the layout of the other svn-switched
> sub-directories of the federated build.
>
> I'll take a look at moving the dependencies in classlib to common_resources
> but before I force everyone working on classlib to checkout common_resources
> I'd like to get this resolved so we don't end up breaking it later.
Sorry, here is somewhat belated recollection: it makes sense to modify
the federated structure a bit further and make common_resources
plugged as svn:externals rather than svn-switch it. This way we'd have
the same versioning abilities plus can benefit reusing same
properties.xml, svn info utilities, etc in the federated build.xml via
direct import.
If you did not yet finish with this, it is a good time to include the
above change as well.
Thanks,
Alexey
>
> - -Mark.
>
> On 4 February 2008 at 16:51, "Alexey Varlamov" <al...@gmail.com>
> wrote:
> > Folks,
> >
> > The new build system for DRLVM is now the offical one, our integrity
> > and snapshot CC systems were switched to it before this weekend.
> > Currently there is certain duplication of resources between the new
> > and old systems (property files, etc); I suggest we drop the old
> > system in a week or two.
> > Also, the old build directory encloses x-lists and MSVC solutions.
> > X-lists apparently should be moved closer to test sources, but what
> > about the solutions - just move them to working_vm/make? AFAIU they
> > need update to changed deploy dir names, any volunteers?
> > Meanwhile please be careful to update the right files, those in
> > <working_vm>/make tree.
> > I've updated GettingStarted page to reflect build changes, and will
> > update README.txt soon. Hopefully the transition to unified build
> > interface will be smooth for DRLVM developers.
> >
> > --
> > Alexey
> >
>
>
> ------- End of Forwarded Message
>
>
>
>
>
>