All externals on 2.0.x except data/citewfs-1.1-h2/workspaces still point to trunk.
Any objection to me changing them all? Or should this be left to module maintainers? (I'll do the app-schema one in any case [it points to GT trunk {naughty, naughty}].)
Changed externals will require everyone to delete the affected directories and re-checkout. Hudson maintainers, do your Hudson's "svn up" or "rm -rf; svn co"?
This happened before in 1.6.x, which was broken by changes to trunk paths because it had trunk externals. Should fixing externals be added to the branch procedure?
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
All externals on 2.0.x except data/citewfs-1.1-h2/workspaces still point to trunk.
Any objection to me changing them all? Or should this be left to module maintainers? (I'll do the app-schema one in any case [it points to GT trunk {naughty, naughty}].)
Yeah, I think that should be fixed.
Changed externals will require everyone to delete the affected directories and re-checkout. Hudson maintainers, do your Hudson's "svn up" or "rm -rf; svn co"?
It does svn up. We might need to wipe out the checkouts once manually
for this change (not such a big deal).
If you go ahead close to the italian morning I can fix the build shortly
after when I wake up (I'm around now too, but it's late for you, isn't
it?)
This happened before in 1.6.x, which was broken by changes to trunk paths because it had trunk externals. Should fixing externals be added to the branch procedure?
Yep, good idea. You do it? 
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 10/11/09 15:28, Andrea Aime wrote:
Ben Caradoc-Davies ha scritto:
All externals on 2.0.x except data/citewfs-1.1-h2/workspaces still point
to trunk.
Any objection to me changing them all? Or should this be left to module
maintainers? (I'll do the app-schema one in any case [it points to GT
trunk {naughty, naughty}].)
Yeah, I think that should be fixed.
Changed externals will require everyone to delete the affected
directories and re-checkout. Hudson maintainers, do your Hudson's "svn
up" or "rm -rf; svn co"?
It does svn up. We might need to wipe out the checkouts once manually
for this change (not such a big deal).
If you go ahead close to the italian morning I can fix the build shortly
after when I wake up (I'm around now too, but it's late for you, isn't
it?)
Not too late. I'll do it now.
This happened before in 1.6.x, which was broken by changes to trunk
paths because it had trunk externals. Should fixing externals be added
to the branch procedure?
Yep, good idea. You do it?
OK, will do.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
On 10/11/09 16:01, Ben Caradoc-Davies wrote:
On 10/11/09 15:28, Andrea Aime wrote:
If you go ahead close to the italian morning I can fix the build shortly
after when I wake up (I'm around now too, but it's late for you, isn't
it?)
Not too late. I'll do it now.
It is done. Fresh checkout succeeded. I will make a test build, but it looks good.
This happened before in 1.6.x, which was broken by changes to trunk
paths because it had trunk externals. Should fixing externals be added
to the branch procedure?
Yep, good idea. You do it?
OK, will do.
The long-term solution, which requires all svn clients to be version 1.5 or later, is to use relative externals:
http://subversion.tigris.org/svn_1.5_releasenotes.html#externals
Relative (internal) externals would require no maintenance when branching. Only external externals (yes, I am turning into Donald Rumsfeld) would require an absolute URI (I use one of these in app-schema to get GeoTools app-schema test data for integration tests).
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
On 10/11/09 16:01, Ben Caradoc-Davies wrote:
On 10/11/09 15:28, Andrea Aime wrote:
If you go ahead close to the italian morning I can fix the build shortly
after when I wake up (I'm around now too, but it's late for you, isn't
it?)
Not too late. I'll do it now.
It is done. Fresh checkout succeeded. I will make a test build, but it looks good.
It seems Hudson had no issues with the change, the build worked fine.
This happened before in 1.6.x, which was broken by changes to trunk
paths because it had trunk externals. Should fixing externals be added
to the branch procedure?
Yep, good idea. You do it?
OK, will do.
The long-term solution, which requires all svn clients to be version 1.5 or later, is to use relative externals:
http://subversion.tigris.org/svn_1.5_releasenotes.html#externals
Relative (internal) externals would require no maintenance when branching. Only external externals (yes, I am turning into Donald Rumsfeld) would require an absolute URI (I use one of these in app-schema to get GeoTools app-schema test data for integration tests).
Yeah, makes sense. The current stable svn client is 1.6.
I think most Linux distributions are using 1.5 by default
However people using CentOS are still on svn 1.4 afaik.
Well, let's make a poll
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 10/11/09 16:36, Andrea Aime wrote:
It seems Hudson had no issues with the change, the build worked fine.
Good. My fresh checkout and build also worked fine.
For the benefit of other developers, the reason why a fresh checkout is essential is that "svn up" will not refresh a changed external URL, which is only followed at chekout time. A working copy will silently retain a checkout from an old URL. In this case, that would leave you with a mix of 2.0.x and trunk. Not good, not good!
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
On 10/11/09 16:36, Andrea Aime wrote:
It seems Hudson had no issues with the change, the build worked fine.
Good. My fresh checkout and build also worked fine.
For the benefit of other developers, the reason why a fresh checkout is essential is that "svn up" will not refresh a changed external URL, which is only followed at chekout time. A working copy will silently retain a checkout from an old URL. In this case, that would leave you with a mix of 2.0.x and trunk. Not good, not good!
Heh, doing a full checkout every time is too expensive, our build boxes
are not that powerful.
I'll do a manual rm -rf in the Hudson checkout
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 10/11/09 17:12, Andrea Aime wrote:
Heh, doing a full checkout every time is too expensive, our build boxes
are not that powerful.
Agreed. My build bots also "svn up"; it is usually more than enough for normal activity, much more efficient, and only vulnerable to structural changes such as this one, which are infrequent. We should not waste CPU power or otherwise unnecessarily deplete our natural resources.
I'll do a manual rm -rf in the Hudson checkout
Thanks!
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
On 10/11/09 17:06, Ben Caradoc-Davies wrote:
For the benefit of other developers, the reason why a fresh checkout is
essential is that "svn up" will not refresh a changed external URL,
which is only followed at chekout time. A working copy will silently
retain a checkout from an old URL. In this case, that would leave you
with a mix of 2.0.x and trunk. Not good, not good!
I would like to retract this baseless assertion! Reading the subversion docs ("Externals Definitions") indicates that "svn up" does notice and recursively update a changed svn:externals definition. Furthermore, I have confirmed this behaviour in practice using a test repo.
The probably reason I was seeing no apparent update of the externals with "svn up" was that the old and new contents were identical, having not deviated since the branch, and svn is clever enough to notice this and detect that there is nothing to do. Cleverer than me, apparently.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia