On Tuesday, July 31, 2012 4:07:17 PM UTC+2, Stefan Sperling wrote: > > On Mon, Jul 30, 2012 at 10:13:37AM +0100, Marcel Hesselbarth wrote: > > Hi Developers, > > > > I'm redirected here from the tortoise mailing list, as they think this > > feature belongs to the area of the svn library. Performing some > > searches shows that I'm not the only one with this problem, even it it > > seems to be never posted here. > > > > The basic problem I have is I have a Project with svn:externals > > defined pointing into the same SVN. When I now make a tortoiseSVN > > commit the files changed inside the svn:externals folders are included > > - so all works great. > > > > If I now try to merge these commit into a other checkout the changes > > inside the svn:externals are not merged, they are silently ignored. I > > need to do a separate merge at the svn:externals folders. Doing so > > works fine, but why having to do this manually? As externals are > > silently included into commits it is easily overseen that a commit > > includes externals at merging. So if these externals are not merged or > > at least warned while merging they will be overseen -> an great source > > for new bugs... > > > > The merge of svn:externals is not done automatically independent of if > > the folder at the merge target is an linked svn:externals folder or a > > real folder. > > > > > > > > Now a detailed example for better visualisation: > > I have the following svn structure: > > svn://svn/test/main/trunc > > svn:external Propery: svn://svn/test/sub/trunc sub > > File: Mainfile.txt > > svn://svn/test/sub/trunc Project > > File: Subfile.txt > > > > Now I make a branch and set the svn:external Propery: > > svn://svn/test/main/branch1 > > svn:external Propery: svn://svn/test/sub/branch1 sub > > File: Mainfile.txt > > svn://svn/test/sub/branch1 Project > > File: Subfile.txt > > > > > > On a Checkout of main Project this will result in the following file > structures: > > mainTrunc > > | Mainfile.txt > > | sub > > | | Subfile.txt > > mainBranch > > | Mainfile.txt > > | sub > > | | Subfile.txt > > > > > > If I make changes at Mainfile.txt and Subfile.txt at main in one > > commit with version 123. To merge these changes to the branch I have > > to do the following: > > 1. Go to mainBranch folder an merge svn://svn/test/main/trunc version > 123 > > 2. Go to mainBranch/sub folder and merge svn://svn/test/sub/trunc > version 123 > > All information required for the 2. merge of the externals folder is > > already known by the tortoise client. It knows there are files at the > > svn://svn/test/sub/trunc folder included at these commit and it knows > > these files are loyally stored at mainBranch/sub folder. > > > > > > > > With best regards, > > Marcel Hesselbarth > > > > This is a known and documented issue with externals. > > The Subversion book says this on the topic: > <quote> > Perhaps most disappointingly, the working copies created via the externals > definition support are still disconnected from the primary working copy > (on > whose versioned directories the svn:externals property was actually set). > And > Subversion still truly operates only on nondisjoint working copies. So, > for > example, if you want to commit changes that you've made in one or more of > those > external working copies, you must run svn commit explicitly on those > working > copies—committing on the primary working copy will not recurse into any > external ones. > http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html > <end quote> > > There are reasons for not committing from externals by default. > For example, you might not have commit privileges for the repository > an externals is pointing at. If Subversion tried to commit to that > repository every time you make a commit that would be rather annoying. > > That said, we're trying to lift some of these limitations with externals. > In particular, there will be a new --include-externals option for 'svn > commit' in Subversion 1.8. This option causes recursive commit from the > parent working copy as well as all externals within the working copy. > > It might be possible to add this option to 'svn merge' as well, to address > your particular use case. You'd have to run a merge with > --include-externals > to tell Subversion "please consider the externals in my working copy > as part of the merge target". I think this is a valid feature request > and if you like you can open a new ENHANCEMENT issue (see > http://subversion.apache.org/reporting-issues.html for more information) > and name me as your bug buddy. > > However it is probably not as trivial to implement as it sounds. > I would guess that this task would make a nice google summer of code > project, i.e. somebody with little or no prior experience with > Subversion's > code base would probably need about 3 months to get this feature > implemented in a quality worth releasing. Maybe you know an intern > or student who would like to help? :) >
would it be possible to have such an option on "svn ls" as well? to my surprise it also silently ignores svn:externals, while e.g. svn co or svn up does not. rupert
