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? :)
Received on 2012-07-31 16:07:53 CEST