> -----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 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
Received on 2011-05-11 16:52:49 CEST