Hi everybody,

I am following this feature with a lot of interest!

One question pops up:
1. Suppose I have a branch "B" with external references to "E"
2. "E" has an external reference to "F"

When I copy "B" to "C" with --pin-externals, then
1. The external reference "E" will be pinned to e.g. "E@999".
2. I suppose "Within" the repository/branch "E", "F" won't be pinned to
"F@888"

Is this correct?

I understand this is not what subversion wants/can do since
"E" may be in another repository where you don't have access to.
But this *does limit* the use-cases of the --pin-externals.

You a mind-storm of me (as a subversion administrator/user):

Another solution may be to add extra metadata to the externals
definition which allows *recursively* pin externals?

E.g. In case of external to another server / repository:
Instead of
        <schema>://<server>/path/to/E@999
Use
        <schema>://<server>/path/to/E@999 --pinned-external
        <schema2>://<server2>/path/to/F@888

With best regards,
Tom.

On wo, 2015-01-28 at 10:54 +0100, Stefan Sperling wrote: 
> I'd like to start a vote about merging the pin-externals branch to trunk.
> 
> This command shows the changes to be merged:
>     svn diff https://svn.apache.org/repos/asf/subversion/trunk@1655241 \
>       https://svn.apache.org/repos/asf/subversion/branches/pin-externals
> 
> Below is a full log message for the entire changeset.
> 
> [[[
> Add a '--pin-externals' option to 'svn copy'.
> This option enables automated pinning of URLs in svn:externals properties
> during copy operations (issue #1258).
> 
>   --pin-externals          : pin externals with no explicit revision to their
>                              last-changed revision (recommended when tagging)
> 
> This feature makes the svncopy.pl contrib script unnecessary.
> 
> Externals are "pinned" by adding a peg revision to the external's source URL.
> For example, the external definition:
>   ^/foo/bar ext_bar
> might become:
>   ^/foo/bar@400 ext_bar
> 
> An external that is already pinned is left as-is.
> 
> There is a known problem where relative URLs in the externals definition
> may become absolute when pinned. This happens if the URL of an external
> resolves to a different path at its last-changed revision. For instance,
> an external definition at r600 might look like this:
>   ^/moo/bar ext_bar
> If the last-changed revision of /moo/bar resolves to r500, and 'moo'
> was renamed from 'foo' between r500 and r600, then the pinned external
> will use an absolute URL in the current implementation:
>   http://svn.example.com/svn/repos/foo/bar@500 ext_bar
> This problem could probably be solved by adding additional APIs which
> resolve the URL http://svn.example.com/svn/repos/foo/bar to a particular
> type of relative URL (such as ^/foo/bar, /svn/repos/foo/bar, ../foo/bar,
> //svn.example.com/svn/repos/foo/bar, or ^/../repos/foo/bar). Additionally,
> APIs which provide information about the type of a given relative external
> URL would be neded. Currently, our APIs don't offer such functionality.
> 
> * subversion/tests/cmdline/externals_tests.py
>   (copy_pin_externals, test_list): New test. Checks REPOS->REPOS, REPOS->WC,
>    WC->REPOS, and WC->WC copies. Verifies that moved items are handled
>    correctly when pinned to pre-move revisions, and tests copies from old
>    revisions.
> 
> * subversion/svn/svn.c
>   (svn_cl__longopt_t): Add opt_pin_externals.
>   (svn_cl__options, svn_cl__cmd_table): Add --pin-externals option.
>   (sub_main): Handle --pin-externals option.
> 
> * subversion/svn/cl.h
>   (svn_cl__opt_state_t): Add pin_externals option.
> 
> * subversion/svn/copy-cmd.c
>   (svn_cl__copy): Use svn_client_copy7().
> 
> * subversion/include/svn_client.h
>   (svn_client_copy7): Declare.
>   (svn_client_copy6): Deprecate.
> 
> * subversion/libsvn_client/client.h
>   (svn_client__remote_propget): Declare.
> 
> * subversion/libsvn_client/prop_commands.c
>   (remote_propget): Rename to svn_client__remote_propget().
>   (svn_client_revprop_set2, svn_client_propget5): Update callers.
> 
> * subversion/libsvn_client/copy.c
>   (external_location_segments_receiver_baton,
>    external_location_segments_receiver): New.
>   (pin_externals_prop, resolve_pinned_externals,
>    queue_externals_change_path_infos,
>    queue_prop_change_commit_items): New helpers.
>   (do_wc_to_wc_copies_with_write_lock, do_wc_to_wc_copies): Implement 
> externals
>    pinning for WC->WC copies.
>   (path_driver_info_t, path_driver_cb_func): Add functionality for pinning
>    externals during copies involving the repository.
>   (repos_to_repos_copy): Implement externals pinning for repos->repos copies.
>   (wc_to_repos_copy): Implement externals pinning for wc->repos copies.
>   (repos_to_wc_copy_single): Implement externals pinning for repos->wc copies.
>   (repos_to_wc_copy_locked, repos_to_wc_copy, try_copy): Pass new parameters
>    on to other functions.
>   (svn_client_copy7): New variant of svn_client_copy() which supports a new
>    'pin_externals' boolean argument.
>   (svn_client_move7): Pass FALSE for pin_externals while copying.
> 
> * subversion/libsvn_client/commit_util.c
>   (do_item_commit): Don't assume that local_abspath is always non-NULL
>    for property modifications. Makes it possible to commit property mods on
>    copied-along children. Attemping this lead to a NULL-deref before.
> 
> * subversion/libsvn_client/deprecated.c
>   (svn_client_copy6): Moved here.
> ]]]

-- 

________________________________________________________________________


| tom.ghyseli...@excentis.com
|
| Tom Ghyselinck
| Senior Engineer
| Excentis N.V.
| Gildestraat 8 B-9000 Ghent, Belgium
| Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74

________________________________________________________________________

Reply via email to