Hello again, I just noticed my previous email got somewhat scrambled.
The idea was to have notation like the following ../../common/module1@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 <danie...@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@R <../../common/module1@relative>ELATIVE module1 > > > > or similar in the external definition. > > > > +1 > > > > Thanks, > > Stefan >
