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

RE: externals not respected until committed

From: Bert Huijben <bert_at_qqmail.nl>
Date: Sun, 24 Apr 2011 12:24:08 +0200

> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
> Sent: zondag 24 april 2011 11:08
> To: Subversion Development
> Subject: Re: externals not respected until committed
>
> On 24.04.2011 11:01, Stefan Sperling wrote:
> > On Sun, Apr 24, 2011 at 10:48:44AM +0200, Stefan Küng wrote:
> >> Hi,
> >>
> >> This happened sometime last week I guess, since I'm updating TSVN to
> >> use the latest SVN trunk usually on weekends:
> >>
> >> When I set an svn:external property, it isn't respected on an update
> >> until I commit the property. Before, I could set or modify an
> >> external property, then run update to get the changes, do my testing
> >> and *then* commit the property change. Now I have to first commit
> >> the property change. That's not good - I'd like to test such a
> >> change first before I commit it.
> >
> > It's going to come back, but possibly as an optional feature.
> > See http://svn.haxx.se/dev/archive-2011-04/0324.shtml
>
> That post talks about such properties on added directories.
> But it doesn't work for existing directories either:
> I have my 'ext' folder for years now in the TSVN repository and the
> svn:externals property is on that folder for the same amount of time.
> It's not freshly added.
>
> I only modify that property, which existed before and now only points to
> a different revision and/or a different tag.

That post should have talked about 'local changes' instead of just added
directories which are just one kind of local change.

Over the last few minor Subversion releases (1.2-1.6) we started to
sometimes respect local changes to the svn:externals property instead of
only their committed version.
(The thread goes into more details and I expect we will look at this topic
at SvnDay in more detail)

But the result is: You can either have a guaranteed stable externals
behavior where externals are always modified/followed (and file externals
can be properly removed) or you can allow local changes to svn:externals to
be processed.

But you simply can't have both, unless we design a new way to process
externals (with its own storage model), which is currently not in the 1.7
roadmap.

For 1.7 there will probably be a flag which will allow you to shoot yourself
in the foot by processing local-only versions of svn:externals properties.
Which resolves the common "How can I test svn:externals?" and "Can I have my
own externals to override the repository ones?" (mini-viewspec) scenarios.
(Suggestions for the '--argument-name' are welcome. --force is already
taken)

But users should know that when they process svn:externals this way they can
see issues like #3351 (there may be moe), which they can't recover from
without a new checkout (or some low level external hacking).
(See the thread for more details)

When users only use directory externals it's usually safe to use this mode;
but there is no way to check for file vs directory externals when processing
just the property in libsvn_wc.

        Bert

>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
Received on 2011-04-24 12:24:44 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.