Re: Relative Revision on Relative Path External

Hello again,

I just noticed my previous email got somewhat scrambled.

The idea was to have notation like the following

../../common/module1_at_RELATIVE module1

in order to peg an external to the revision of the folder owning the the
external property.

The reason why I would like such a feature is because
we have a product that gets packaged with various plugins.

Each plugin is independently tested by QA.

We have a branch call "staging" with is pretty much a folder with external
properties.

Our external property on this "staging" folder looks something like this

https://svn.ingenius.com:8443/svn/ICE/trunk/Build@2483 Build
https://svn.ingenius.com:8443/svn/ICE/trunk/Server@2483 Server
https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/TypeA/Plugin1@2483
 Plugins/TypeA/Plugin1
https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/TypeB/Plugin1@2486
 Plugins/TypeA/Plugin1
https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/Plugins/TypeC/Plugin1@2509
 Plugins/TypeC/Plugin1
https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/Plugins/TypeC/Plugin2@2310Plugins/TypeC/Plugin2
https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/Plugins/TypeC/Plugin3@2520Plugins/TypeC/Plugin3
https://svn.ingenius.com:8443/svn/ICE/trunk/Setup@2483 Setup
https://svn.ingenius.com:8443/svn/ICE/trunk/Tools/ToolA@2483 Tools/ToolA
https://svn.ingenius.com:8443/svn/ICE/trunk/Tools/ToolB@2483 Tools/ToolB
https://svn.ingenius.com:8443/svn/ICE/trunk/Tools/ToolC@2483 Tools/ToolC

This allows us to bring in the various components at their latest general
QA accepted revision and
makes for an incredibly convenient means to manage releases.

The idea being that we simply move the peg revision on a plugin in order to
include the latest QA approved plugin
in a release candidate build.
After QA approved the candidate we simply tag the staging branch as a
release.

The problem is that for this to work I first have to peg all the relative
externals of a plugin on the trunk.
Then peg that revision for "staging" so that the externals of that external
are exported at the right revision.
Then unpeg the trunk again so that development occurring on trunk gets the
head revision.

This is very cumbersome.

Branching the entire trunk to peg the relatively path externals on the
plugins is also cumbersome.

Allowing for a RELATIVE peg on relative externals would a welcome addition.

Here are the two links I was able to find were some other folks are looking
for a similar solution to meet their needs.

http://stackoverflow.com/questions/13297244/svn-externals-and-revision-association

http://www.svnforum.org/threads/41345-revision-inheritage-in-svn-externals

Thanks,
Stefan

On Tue, Dec 11, 2012 at 4:14 AM, Daniel Shahaf <danielsh_at_apache.org> wrote:

> Stefan Scherer wrote on Mon, Dec 10, 2012 at 16:09:47 -0500:
> > I would like to be able to peg <p2> in product to a particular revision
> and
> > have <module1> and <module2>
> > be of that same revision without having to maintain the peg
> > at trunk/plugin/p1/EXTERNALS which would have to
> > be constantly moving.
> >
> >
> >
> http://stackoverflow.com/questions/13297244/svn-externals-and-revision-association
> >
> http://www.svnforum.org/threads/41345-revision-inheritage-in-svn-externals
> >
> > How about a new feature to allow
> >
> > ../../common/module1_at_R <../../common/module1_at_relative>ELATIVE module1
> >
> > or similar in the external definition.
> >
>
> +1
>
>
> > Thanks,
> > Stefan
>
Received on 2012-12-12 20:13:35 CET