On Thu, May 12, 2011 at 12:12 AM, Bert Huijben <b...@qqmail.nl> wrote:
> > > > -----Original Message----- > > From: Hans-Emil Skogh [mailto:hans-emil.sk...@tritech.se] > > Sent: woensdag 11 mei 2011 15:48 > > To: dev@subversion.apache.org > > Subject: RE: WC-NG, externals and fast properties > > > > Thanks for your quick and detailed response! > > > > >> I noticed recently that the behavior when working with externals have > > >> changed in SVN 1.7. Local changes to the svn:externals property in the > > >> working copy is by default not honored during an update, before a > > commit. > > > There are fundamental problems with how we have to process the > > svn:externals > > > property: we need the version *exactly* how it was at the last svn > update > > > and the 'latest' version, to make the svn:externals processing handle > > > definition changes. > > > (We really need the *CHANGES of externals*...) > > ... > > > But the real solution is to add a store which contains what externals > we > > > knew at the last update. > > > > Ah. We need the pristine versions of the properties. But they must be > > known already, or reverts of property changes would not work. What am I > > missing here? > > If you do > Assuming you committed > $ svn propset svn:externals A . > $ svn up . > (updates externals to match definition nothing->A) > > $ svn ci -m"" > $ svn propset svn:externals B . > $ svn update . > > Then currently this updates the directory to the definition A (just to be > safe), while you (and many others) would like it to go to B. > > So assume the preferred scenario this would do the update A->B > > But then you have the even likely case > $ svn propset svn:externals C > $ svn update . > > This would then apply A->C, so this could potentially break your working > copy, by leaving traces of B. > > We really need the step B->C here, but there is no way to access B, because > it wasn't committed. It just lived in a local property change. > Just curious, but why do we care about 'B' here? It sounds as though we're assuming that the svn:externals property is related to the same repository, or potentially the same path (to a different peg revision). What would happen if A->B change was from ^/tags/release-1.1.1 to <repository2/tags.release-1.1.1? An update wouldn't work, and if this was a full working copy, it would need to be completely checked out again. Apologies if this is a stupid question. Cheers, Daniel B.
