On 16.02.2015 20:47, Stefan Kueng wrote:
>
>
> On 16.02.2015 20:39, Stefan Sperling wrote:
>> On Mon, Feb 16, 2015 at 08:01:19PM +0100, Stefan Kueng wrote:
>>> Hi,
>>>
>>> I'm still doing some testing with the new --pin-externals feature,
>>> and I
>>> found a situation which I'm not sure should be handled that way:
>>>
>>> imagine the repo is at r100. Now if one does a
>>> svn copy http://server/trunk http://server/branches/b1 -r50
>>> --pin-externals
>>>
>>> then all externals get pinned at r100. But shouldn't in-repo
>>> externals get
>>> pinned to r50 instead? At least in this kind of copy, I think those
>>> externals should get pinned to r50?
>>
>> In general, externals point at different repositories. So your
>> expectation
>> that any of the revision numbers involved in the copy process have
>> anything
>> to do with pinning is misguided. An intra-repository external (and
>> especially
>> a configuration where all externals come from the same repository) is
>> a special
>> case where I don't think it is wise to make pinning behave any
>> differently.
>
> I don't think that intra-repository externals are really that special.
> A lot of our users, especially those in big corporations use those
> extensively - they often have one big repository with all their
> projects as subfolders.
> And for all those setups, it would really make sense to pin those
> externals to the same revision the copy was made from.
AFAIK, 'svn update -rX' will update externals to HEAD, not to revision
X. Even if they're in-repos externals. So making 'svn copy
--pin-externals' do the same makes sense.
Using externals to track dependencies is always a tricky proposition;
typically, you should point the external to a tag or pin it with a peg
revision, otherwise you don't have any control over which version of the
dependency you're using. And Subversion is not a dependency tracker.
FWIW, one can always do a WC->REPO tag; that'll pin the externals to
their current revisions in the working copy.
-- Brane
Received on 2015-02-16 22:23:42 CET