If you have the A->B->C path then that external to ^/tags/release-1.1.1
would be removed for you and a new external svn://server2/repos2/tags.1.2.2
would be checked out in its place.
(Assuming that there are no changes in that external, no user action
required. Otherwise you would have some unversioned files left, with your
modifications)
If you don't have B, you would get an error that there is an obstructing
working copy blocking your new external. And you may try fixing it yourself.
(Or call your local Subversion administrator for help)
And if it happens on a file external instead of a directory external, you
can only delete your parent working copy (including all the externals) and
perform a new checkout to recover.
Bert
From: Daniel Becroft [mailto:djcbecr...@gmail.com]
Sent: woensdag 11 mei 2011 22:39
To: Bert Huijben
Cc: Hans-Emil Skogh; dev@subversion.apache.org
Subject: Re: WC-NG, externals and fast properties
On Thu, May 12, 2011 at 12:12 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.
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.
