Bert: this design was not clear to me until you explained it below. Hyrum has already asked for something in notes/ to help the rest of us out.
Could you do that? On May 11, 2011 10:52 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. > >> > And I'm working on that right now. Once that store is operational > (guess: by >> > the end of this week), we can safely re-enable local changes to >> > svn:externals, but without the problems of the past. >> >> Oh! That's great! Good to know that someone is looking into this. >> >> When you are writing "store", I guess you are referring to something other >> than the wc database. If that is so, what is the reason not to put it in > the >> database? > > It is a new table in wc.db. So, no it is not something else. > > This store will always hold the last state of every external. > > So it will just allow updating externals from LAST-status to something-new, > so following the example above, it will allow us to see B and then we can > just do the B->C step. > (And by storing the data externally it is easier to access. And most of the > cases that could break your WC are also gone) > > Bert >
