subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "rupert.thurner" <rupert.thur...@gmail.com>
Subject Re: FeatureRequest: Improved svn:externals handling on Merge
Date Mon, 03 Sep 2012 08:13:28 GMT

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

 

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message