Db based configuration for per-directory access control
Hi all Is there any way to configure subversion to do per-directory access control via database not config file? I have googled a lot, and all found are telling how to configure apache login problem, not svn repository access control.
Re: repo structure change and external definitons
>> Von: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] >> Gesendet: Wednesday, November 24, 2010 12:52 PM >> An: Schroeder, Hartmut >> Cc: users@subversion.apache.org >> Betreff: Re: repo structure change and external definitons >> >> On Nov 24, 2010, at 05:00, Schroeder, Hartmut wrote: >> >>> say, >>> svn list http://server/repo/trunk/a/b/c >>> gives: >>> d/ >>> in revision 100. >>> >>> Then: >>> svn del http://server/repo/trunk/a/b/c/d >>> (r101) >>> >>> Then, the checkout >>> svn co -p 100 http://server/repo/trunk/a/b/c/d >>> won't work, but with the peg revision >>> svn co http://server/repo/trunk/a/b/c/d...@100 >>> it does. >>> >>> All external definitons using '-p 100 http://server/repo/trunk/a/b/c/d' >>> won't work anymore and need to be changed. That leeds to heavy >>> discussions cause some teams here using a lot of external definitons and >>> run into that problem. >>> >>> We are using Subversion 1.5.5 >>> >>> Does a reason exist for that behaviour? >>> Is it a point of change in upcoming releases? >>> Is there a nice workaround? >>> Or, is the only solution to use always peg revisions in external >>> definitions? >> >> For exactly the reasons you've discovered, you should always use peg >> revisions in externals definitions. > On Nov 24, 2010, at 07:28, Schroeder, Hartmut wrote: > it would be a good idea to update the documentation, first to give a big > warning if one moves or deletes an entry and second to recommend externals > definitons only with peg revisions. today that is not the case. That sounds like a good idea to me. The book has its own mailing list and issue tracker where you could bring this issue to the authors' attention.
Re: Apache Subversion 1.6.15 Released
On Wed, Nov 24, 2010 at 05:36:01PM -0500, Nico Kadel-Garcia wrote: > On Wed, Nov 24, 2010 at 11:15 AM, Hyrum Wright wrote: > > I'm happy to announce Apache Subversion 1.6.15. This release contains > > several bug fixes, including two which can cause client-initiated > > crashes on the server. We encourage users to upgrade as soon as > > Cool. I just built it using the RPMforge SRPM's, updated to 1.6.15, > and it passwd with flying colors in my RHEL 5 environment. I left a > request on the relevant mailing list there to update the package: we > should see an update quite soon for RHEL 5 and CentOS 5 users. Thanks for poking rpmforge. BTW, OpenSUSE/SLE users can find 1.6.15 packages in the buildservice: http://software.opensuse.org/search?q=subversion+1.6.15 Some are still building so if your SUSE version or processor architecture doesn't show up in the list yet try again later. Stefan
Re: Apache Subversion 1.6.15 Released
On Wed, Nov 24, 2010 at 11:15 AM, Hyrum Wright wrote: > I'm happy to announce Apache Subversion 1.6.15. This release contains > several bug fixes, including two which can cause client-initiated > crashes on the server. We encourage users to upgrade as soon as Cool. I just built it using the RPMforge SRPM's, updated to 1.6.15, and it passwd with flying colors in my RHEL 5 environment. I left a request on the relevant mailing list there to update the package: we should see an update quite soon for RHEL 5 and CentOS 5 users.
RE: Find file in repo
Thanks a lot, this solved my problem. Best regards > Date: Tue, 23 Nov 2010 13:06:16 +0100 > From: pi...@kabot.net > To: users@subversion.apache.org; rob_gar_...@hotmail.com > Subject: Re: Find file in repo > > On 23-11-2010 12:49, Gerardo Corro wrote: > > How can I get the path of one file in a SVN repo? > > > > Supouse I want to find a file named "LoginInterceptor.c" with its > > complete path in one SVN repo. > > Hi, maybe it's not exactly what you are asking for, but try to use > something like this: > svn ls -R svn://svnserver/repo | grep LoginInterceptor.c > > -- > Piotr Kabacinski > a2Fib3Q=
Re: svnsync_test.py fails: wrong version of SQLite library
The documentation on how to use the amalgamation should be clearer. After many false starts, I got it to successfully configure with: ./configure --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/tmp/sqlite-3.7.3/sqlite3.c I'm mildly surprised that it can't find sqlite3.c if you feed it a directory with the amalgamation file in it (--with-sqlite=/tmp/sqlite-3.7.3). I'm somewhat less surprised in it being unable to unpack a tarball to find the appropriate file. Note that without having found the right bit of SQLite documentation, SQLite's distribution file is what I would assume is the 'amalgamation', as it has that word in its name. That said, it built fine, and passed all tests. Thanks for the pointer! MJB On 11/23/2010 9:18 PM, Hyrum K. Wright wrote: On Tue, Nov 23, 2010 at 6:16 PM, Michael J. Bauer wrote: I am attempting to build SVN on a RHEL 5.4 system. There are two versions of SQLite on the system: * The stock system SQLite, version 3.3.6, with library in /usr/lib * A new version of SQLite, version 3.7.3, with library in /usr/sup/lib I configured SVN with the following options: ./configure --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/ (The prefix is because I do not want to clobber the system version of SVN, just make a newer one available.) The build worked without issue; however, 'make check' fails. When I look at the log, I see the following error repeatedly: svnsync: SQLite compiled for 3.7.3, but running with 3.3.6 It looks like svnsync is picking up the wrong version of SQLite, despite being compiled with the correct version. This appears to happen only on svnsync synchronize, but I've not exhaustively read through the logs. I've re-run the tests with LD_LIBRARY_PATH, LD_RUN_PATH, and LIBRARY_PATH set identically to /usr/sup/lib:/usr/local/lib, to no change in behavior. To make sure I wasn't missing something, I rebuilt SVN, configuring it with explicit environment variables: ./configure LDFLAGS=-L/usr/sup/lib CPPFLAGS=-I/usr/sup/include --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/ It fails 'make check' in exactly the same way. When I look at subversion-1.6.13/subversion/svnsync/svnsync, the shell script appears to be clobbering the run-time environment variables. I'm not sure this is pertinent, given that it fails with or without the run-time variables set, and with or without LDFLAGS and CPPFLAGS set. How do I get SVN to pick up the correct version of the library on 'make check' when --with-sqlite (with or without compile-time and run-time environment variables set) doesn't do the right thing? Have you tried building Subversion with the sqlite amalgamation? You can point --with-sqlite at an amalgamation file (as downloaded from sqlite.org), and Subversion will statically include that, removing library conflicts. -Hyrum
Re: svnsync_test.py fails: wrong version of SQLite library
Michael J. Bauer wrote: I see no SVN version 1.6 RPM in RPMForge. It's the first place I looked before trying to build it by hand. Very strange: (trimmed a little) [kdeu...@lilbro ~]$ yum list |grep subversion subversion.x86_64 1.6.13-0.1.el5.rf installed [kdeu...@lilbro ~]$ yum list rpmforge-release rpmforge-release.x86_64 0.5.1-1.el5.rf installed (FWIW, there seems to be an updated rpmforge-release package.) I've had several previous 1.6 SVN versions from RPMForge, and I expect I'll see 1.6.15 within a week or so. -kgd
Re: svnsync_test.py fails: wrong version of SQLite library
Couldn't hurt. There's no need for the whole log though, a representative sample should be enough... Does it fail in the same way under 'make check' as under './svnsync_tests.py -v'? (You can pass TESTS=subversion/tests/cmdline/svnsync_tests.py to 'make check', by the way.) Michael J. Bauer wrote on Wed, Nov 24, 2010 at 12:03:49 -0500: > The only test that failed out of the 71 run by 'make check' was > svnsync_test.py. The only things that appeared to fail within that test > were svnsync sync. I can send the test log if you like. > > MJB > > On 11/24/2010 2:45 AM, Daniel Shahaf wrote: >> Michael J. Bauer wrote on Tue, Nov 23, 2010 at 19:16:32 -0500: >>> It looks like svnsync is picking up the wrong version of SQLite, despite >>> being compiled with the correct version. This appears to happen only on >>> svnsync synchronize, but I've not exhaustively read through the logs. >> I'd be surprised if only svnsync (and MUCH more surprised if only >> 'svnsync sync') complain about wrong libraries. The sqlite library >> should be loaded by other cmdline utilities too...
Re: svnsync_test.py fails: wrong version of SQLite library
I have not tried that method; I'll try it now and report back when 'make check' finishes. MJB On 11/23/2010 9:18 PM, Hyrum K. Wright wrote: On Tue, Nov 23, 2010 at 6:16 PM, Michael J. Bauer wrote: I am attempting to build SVN on a RHEL 5.4 system. There are two versions of SQLite on the system: * The stock system SQLite, version 3.3.6, with library in /usr/lib * A new version of SQLite, version 3.7.3, with library in /usr/sup/lib I configured SVN with the following options: ./configure --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/ (The prefix is because I do not want to clobber the system version of SVN, just make a newer one available.) The build worked without issue; however, 'make check' fails. When I look at the log, I see the following error repeatedly: svnsync: SQLite compiled for 3.7.3, but running with 3.3.6 It looks like svnsync is picking up the wrong version of SQLite, despite being compiled with the correct version. This appears to happen only on svnsync synchronize, but I've not exhaustively read through the logs. I've re-run the tests with LD_LIBRARY_PATH, LD_RUN_PATH, and LIBRARY_PATH set identically to /usr/sup/lib:/usr/local/lib, to no change in behavior. To make sure I wasn't missing something, I rebuilt SVN, configuring it with explicit environment variables: ./configure LDFLAGS=-L/usr/sup/lib CPPFLAGS=-I/usr/sup/include --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/ It fails 'make check' in exactly the same way. When I look at subversion-1.6.13/subversion/svnsync/svnsync, the shell script appears to be clobbering the run-time environment variables. I'm not sure this is pertinent, given that it fails with or without the run-time variables set, and with or without LDFLAGS and CPPFLAGS set. How do I get SVN to pick up the correct version of the library on 'make check' when --with-sqlite (with or without compile-time and run-time environment variables set) doesn't do the right thing? Have you tried building Subversion with the sqlite amalgamation? You can point --with-sqlite at an amalgamation file (as downloaded from sqlite.org), and Subversion will statically include that, removing library conflicts. -Hyrum
Re: svnsync_test.py fails: wrong version of SQLite library
I see no SVN version 1.6 RPM in RPMForge. It's the first place I looked before trying to build it by hand. r...@sunfire60# rpm -i rpmforge-release-0.5.1-1.el5.rf.x86_64.rpm r...@sunfire60# yum list > /tmp/foo r...@sunfire60# grep -i '^svn' /tmp/foo | grep 1.6 r...@sunfire60# grep -i '^subversion' /tmp/foo | grep 1.6 r...@sunfire60# rpm -e rpmforge-release r...@sunfire60# rpm -i rpmforge-release-0.5.1-1.el5.rf.i386.rpm r...@sunfire60# yum list > /tmp/foo r...@sunfire60# grep -i '^svn' /tmp/foo | grep 1.6 r...@sunfire60# grep -i '^subversion' /tmp/foo | grep 1.6 r...@sunfire60# MJB On 11/23/2010 10:12 PM, Nico Kadel-Garcia wrote: On Tue, Nov 23, 2010 at 7:16 PM, Michael J. Bauer wrote: I am attempting to build SVN on a RHEL 5.4 system. There are two versions of SQLite on the system: Use the SRPM or the RPM from RPMforge. I've had some involvement with that: previous contributors included the squlite-amalgmation tarball, which is used at compile time to provide statically loaded libraries and brings it successfully into RHEL 5.x compatibilyy. RHEL 5's version is perilously out of date for both security and performance reasons: I strongly recommend the RPMforge subversion-1.6.13 toolsuite. It's one issue is that RPMforge doesn't publish i386 packages in the same repository as x86_64 packages, and RHEL does, so you have to play yum configuration games to avoid loading the subversion-1.4.2-1.i386.rpm from RHEL, and the subversion-1.6.13-[release].x86_64.rpm from RPMforge and causing chaos.
Re: svnsync_test.py fails: wrong version of SQLite library
The only test that failed out of the 71 run by 'make check' was svnsync_test.py. The only things that appeared to fail within that test were svnsync sync. I can send the test log if you like. MJB On 11/24/2010 2:45 AM, Daniel Shahaf wrote: Michael J. Bauer wrote on Tue, Nov 23, 2010 at 19:16:32 -0500: It looks like svnsync is picking up the wrong version of SQLite, despite being compiled with the correct version. This appears to happen only on svnsync synchronize, but I've not exhaustively read through the logs. I'd be surprised if only svnsync (and MUCH more surprised if only 'svnsync sync') complain about wrong libraries. The sqlite library should be loaded by other cmdline utilities too...
Apache Subversion 1.6.15 Released
I'm happy to announce Apache Subversion 1.6.15. This release contains several bug fixes, including two which can cause client-initiated crashes on the server. We encourage users to upgrade as soon as reasonable. Please note that Subversion 1.6.15 is the next release after Subversion 1.6.13. The 1.6.14 release was not published publicly, due to issues found during testing. Subversion 1.6.15 is available from: http://subversion.tigris.org/downloads/subversion-1.6.15.tar.bz2 http://subversion.tigris.org/downloads/subversion-1.6.15.tar.gz http://subversion.tigris.org/downloads/subversion-1.6.15.zip http://subversion.tigris.org/downloads/subversion-deps-1.6.15.tar.bz2 http://subversion.tigris.org/downloads/subversion-deps-1.6.15.tar.gz http://subversion.tigris.org/downloads/subversion-deps-1.6.15.zip The MD5 checksums are: 113fca1d9e4aa389d7dc2b210010fa69 subversion-1.6.15.tar.bz2 cd7d613d86eb6465fdaf0f34a6cfe9ec subversion-1.6.15.tar.gz 8471a65812c3e6de86945143ebcf7a4b subversion-1.6.15.zip 4aeb48233e62cf4afe9f5700ebed9150 subversion-deps-1.6.15.tar.bz2 db555a4c61cf928a99e10c9788a50149 subversion-deps-1.6.15.tar.gz 1d8c2d7f0e3d0cd8c8c79e7240effb1a subversion-deps-1.6.15.zip The SHA1 checksums are: b6fadf944a94b86f989f07bc2d781be41df017bf subversion-1.6.15.tar.bz2 e587227eff1cf86eec69336738a3aa38dae09dec subversion-1.6.15.tar.gz 61103b1b1a4b753e0cb645b73239f1a9873b0efe subversion-1.6.15.zip 29572d9d4e4a9bbcf6dab006011f5b1d411798b2 subversion-deps-1.6.15.tar.bz2 a29d2c13ad88272c01dc08bc62f88bc4cc53cd22 subversion-deps-1.6.15.tar.gz f267d63925408b052b79c90e06b8a8ee9afc7d2c subversion-deps-1.6.15.zip PGP Signatures are available at: http://subversion.tigris.org/downloads/subversion-1.6.15.tar.bz2.asc http://subversion.tigris.org/downloads/subversion-1.6.15.tar.gz.asc http://subversion.tigris.org/downloads/subversion-1.6.15.zip.asc http://subversion.tigris.org/downloads/subversion-deps-1.6.15.tar.bz2.asc http://subversion.tigris.org/downloads/subversion-deps-1.6.15.tar.gz.asc http://subversion.tigris.org/downloads/subversion-deps-1.6.15.zip.asc For this release, the following people have provided PGP signatures: Senthil Kumaran S [1024D/6CCD4038] with fingerprint: 8035 16A5 1D6E 50E2 1ECD DE56 F68D 46FB 6CCD 4038 Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Paul T. Burba [1024D/53FCDC55] with fingerprint: E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 Julian Foad [1024D/353E25BC] with fingerprint: 6604 5A4B 43BC F994 5728 351F 33E4 353E 25BC Bert Huijben [1024D/9821F7B2] with fingerprint: 2017 F51A 2572 0E78 8827 5329 FCFD 6305 9821 F7B2 Hyrum K. Wright [1024D/4E24517C] with fingerprint: 3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C Stefan Sperling [1024D/F59D25F0] with fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0 Mark Phippard [1024D/035A96A9] with fingerprint: D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9 Release notes for the 1.6.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.6.html You can find the list of changes between 1.6.15 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.6.15/CHANGES Questions, comments, and bug reports to us...@subversion.apache.org. Thanks, - The Subversion Team
Merge with "--accept theirs-conflict" doesn't work as expected - the result is same as with "--accept theirs-full"
Hello, I am having a problem with "merge --accept theirs-conflict": it seems like it is working like "merge --accept theirs-full". I am trying to get changes from different branch and merge them to my working copy (running this command in my working copy directory /some/thing): "svn merge -c 27497 https://svn.server/repos/product/acme/branches/36/some/thing/file.i file.i --accept theirs-conflict " I expect it to work like this: if there is a conflict in a file upon the merge it will take those conflicting parts from "theirs" revision 27497. All changes in revision 27497 should also be merged to my working copy. There should be no other changes merged than those in revision 27947. Now what happens: Merge resolves conflicting parts with "theirs" changes (this is ok) but also makes other changes comparing "theirs" revision to my working copy (?). This means that if revision 27497 includes only line additions the merge will, for some not obvious reason, delete some lines, too (just for an example). I would like to see only those additions in my working copy that are made in revision 27497 - otherwise the file should be untouched. If the merge's result is the same with "theirs-full" and "theirs-conflict", is this a bug? Or is there some other parameter I should use? -- Teemu
AW: repo structure change and external definitons
it would be a good idea to update the documentation, first to give a big warning if one moves or deletes an entry and second to recommend externals definitons only with peg revisions. today that is not the case. hartmut -Ursprüngliche Nachricht- Von: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Gesendet: Wednesday, November 24, 2010 12:52 PM An: Schroeder, Hartmut Cc: users@subversion.apache.org Betreff: Re: repo structure change and external definitons On Nov 24, 2010, at 05:00, Schroeder, Hartmut wrote: > say, > svn list http://server/repo/trunk/a/b/c > gives: > d/ > in revision 100. > > Then: > svn del http://server/repo/trunk/a/b/c/d > (r101) > > Then, the checkout > svn co -p 100 http://server/repo/trunk/a/b/c/d > won't work, but with the peg revision > svn co http://server/repo/trunk/a/b/c/d...@100 > it does. > > All external definitons using '-p 100 http://server/repo/trunk/a/b/c/d' > won't work anymore and need to be changed. That leeds to heavy > discussions cause some teams here using a lot of external definitons and > run into that problem. > > We are using Subversion 1.5.5 > > Does a reason exist for that behaviour? > Is it a point of change in upcoming releases? > Is there a nice workaround? > Or, is the only solution to use always peg revisions in external > definitions? For exactly the reasons you've discovered, you should always use peg revisions in externals definitions.
Re: repo structure change and external definitons
On Nov 24, 2010, at 05:00, Schroeder, Hartmut wrote: > say, > svn list http://server/repo/trunk/a/b/c > gives: > d/ > in revision 100. > > Then: > svn del http://server/repo/trunk/a/b/c/d > (r101) > > Then, the checkout > svn co -p 100 http://server/repo/trunk/a/b/c/d > won't work, but with the peg revision > svn co http://server/repo/trunk/a/b/c/d...@100 > it does. > > All external definitons using '-p 100 http://server/repo/trunk/a/b/c/d' > won't work anymore and need to be changed. That leeds to heavy > discussions cause some teams here using a lot of external definitons and > run into that problem. > > We are using Subversion 1.5.5 > > Does a reason exist for that behaviour? > Is it a point of change in upcoming releases? > Is there a nice workaround? > Or, is the only solution to use always peg revisions in external > definitions? For exactly the reasons you've discovered, you should always use peg revisions in externals definitions.
Re: Should svn allow a merge into a conflicted file?
Hi - I hate to bump this just for the sake of it, but AFAIK an email wasn't sent to the list from this post, maybe because I sent it immediately after registering. cheers, jamie JamieEchlin wrote: > > Should Subversion allow a merge on top of a file that already contains > an unresolved conflict? Run the script below to set up the scenario. > > The first merge introduces a conflict, the second merge contains > incoming changes to the conflicting section. The second merge is applied > successfully to the working copy. However, as the working copy is still > in conflict, when you come to resolve it, the contributors overwrite the > later changes. In the example, the contributors are foo.c.working, > foo.c.merge-right.r4 and foo.c.merge-left.r3. When the merge is > completed the foo.c that had contained the changes from the second merge > are overwritten. > > I think it's a misfeature that svn allows a merge into a file that > already contains conflicts, especially given that multiple pass merges > are broken up for entirely the reason that there is no reliable way to > merge a change into a file that already contains conflicts. > > It may seem unlikely that someone would do a second merge when there is > already conflicts, however this is the case when you pick two separate > source revisions to merge in Tortoise, and then choose to postone > resolving all conflicts - you may not realise there is a conflict in the > first revision as subsequent revisions may be merged successfully. > > Apparently it is documented that you must resolve interactively when > cherrypicking, however I can't find this. Nevertheless, imho the > behaviour in this scenario should be the same as when merging a > non-contiguous range of revisions, ie you are forced to resolve > conflicts after each sub-range. > > Grateful for any opinions on this... and if this is a reported bug, > what's the ID please. > > cheers, jamie > > __SCRIPT__ > > @rem config > SET REPO_PATH=file:///c:/tmp/TestMergeIssue/repo > > rm -rf wc repo > svnadmin create repo > svn co %REPO_PATH% wc > pushd wc > mkdir trunk branches > echo 1 >> trunk\foo.c > echo 2 >> trunk\foo.c > echo 3 >> trunk\foo.c > echo 4 >> trunk\foo.c > echo 5 >> trunk\foo.c > echo 6 >> trunk\foo.c > echo 7 >> trunk\foo.c > echo 8 >> trunk\foo.c > echo 9 >> trunk\foo.c > svn add trunk branches > svn commit -m "1" > > svn cp trunk branches/1.0 > svn commit -m "2" > > @rem change 2nd line on trunk > perl -pi.bak -e "s/2/B trunk/" trunk/foo.c > svn commit -m "3" trunk/foo.c > > @rem add lines on branch > perl -pi.bak -e "s/2/A.ny\nB.ny\nC.ny\nD.ny/" branches/1.0/foo.c > svn commit -m "4" branches/1.0/foo.c > @rem this will conflict now > > @rem modify two of the lines on branch > perl -pi.bak -e "s/C.ny/C/" branches/1.0/foo.c > perl -pi.bak -e "s/D.ny/D/" branches/1.0/foo.c > svn commit -m "5" branches/1.0/foo.c > > pushd trunk > svn merge --accept postpone -c 4 ^^/branches/1.0 > svn merge --accept postpone -c 5 ^^/branches/1.0 > popd > popd > > > === > > Please access the attached hyperlink for an important electronic > communications disclaimer: > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > === > > > > -- View this message in context: http://old.nabble.com/Should-svn-allow-a-merge-into-a-conflicted-file--tp30286560p30296054.html Sent from the Subversion Users mailing list archive at Nabble.com.
repo structure change and external definitons
Hi, say, svn list http://server/repo/trunk/a/b/c gives: d/ in revision 100. Then: svn del http://server/repo/trunk/a/b/c/d (r101) Then, the checkout svn co -p 100 http://server/repo/trunk/a/b/c/d won't work, but with the peg revision svn co http://server/repo/trunk/a/b/c/d...@100 it does. All external definitons using '-p 100 http://server/repo/trunk/a/b/c/d' won't work anymore and need to be changed. That leeds to heavy discussions cause some teams here using a lot of external definitons and run into that problem. We are using Subversion 1.5.5 Does a reason exist for that behaviour? Is it a point of change in upcoming releases? Is there a nice workaround? Or, is the only solution to use always peg revisions in external definitions? Thanks. Regards Hartmut
