[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: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Thu, 12 May 2011 06:39:10 +1000

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
> 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.
Received on 2011-05-11 22:39:57 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.