[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: WC-NG, externals and fast properties

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 11 May 2011 15:34:58 -0400

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" <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Hans-Emil Skogh [mailto:Hans-Emil.Skogh_at_tritech.se]
>> Sent: woensdag 11 mei 2011 15:48
>> To: dev_at_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
>> > 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,
> 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
>> 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
> 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
> cases that could break your WC are also gone)
> Bert
Received on 2011-05-11 21:35:40 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.