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:
>
> 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
>
>
> 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 featur
