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
