On Thu, May 12, 2011 at 12:12 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
> > > 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, 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
that the svn:externals property is related to the same repository, or
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
working copy, it would need to be completely checked out again.
Apologies if this is a stupid question.
Received on 2011-05-11 22:39:57 CEST