dir external can blast away local mods

[Neels J Hofmeyr <ne...@elego.de>]

An svn:externals dir, first checked out onto an already versioned target dir
(during update), blows away local modifications.

[[[
(pseudocode)

$ svn ls
XA/
$ svn diff
--- XA/local_file
+++ XA/local_file
 orig
+very important local mod


$ svn ps svn:externals "^/A XA" .
$ svn update
D   XA/local_file
A   XA/remote_file
svn: warning: W200000: Error handling externals definition for 'XA':
svn: warning: W155035: The specified path has an unexpected status
At revision 3.
svn: E205011: Failure occurred processing one or more externals definitions

$ svn diff XA
$ svn cat XA/local_file
cat: XA/local_file: No such file or directory
]]]

The new externals definition switches the already existing dir XA to the
external URL ^/A. Probably because of the failing consistency check and its
abort, this wipes local modifications from XA/local_file.

When producing a similar situation by changing the dir external's URL, local
mods result in proper tree conflicts: "local edit, incoming delete/replace
upon switch". So the idea is that, hopefully, once above consistency check
doesn't abort the operation in this way, the update will just continue to
flag such tree conflicts, problem solved.


But that got me thinking. It's not so easy to recover local modifications
after a conflicted switch -- ever more tree conflicts, manual labor. I would
rather error early on this situation.

Added weight: since svn:externals may come in from other people, it's not
only you who's doing an 'svn switch' in own responsibility. This potentially
messes up WCs with a simple 'svn update'.

So I'd like to abort the entire dir external update
- if there's a versioned dir already, and
- if it has local mods anywhere, and
- iff the BASE node's URL is different from the URL the dir external wants
to bring in at that path.

User can still commit / diff to the path's original URL without fuss. This
(or as always a revert -R) and a subsequent update would solve any local
update situations with dir externals.

Do you like the idea & do you think that it's reasonably easy to achieve and
backportable?


FYI, comparing to file externals:

File externals are treated a bit stricter, it seems any existing BASE node's
IS_EXTERNAL status is verified before bringing in a file external:
[[[
Fetching external item into 'xa':
svn: warning: W195017: The file external from
'file:///tmp/switch_thru_external_file.vnT/repos/a' cannot overwrite the
existing versioned item at '/tmp/switch_thru_external_file.vnT/wc/xa'
]]]

If I change a successfully created file external's URL in the svn:externals
prop and update, local mods produce a text conflict. This should probably
abort the same way as above.

~Neels

Re: dir external can blast away local mods

[Neels J Hofmeyr <ne...@elego.de>]

Ugh -- I have to note that my test was erratic and what I tought were local
mods were actually committed. Issue #4005 marked invalid.

However, my plan to abort switching externals when there are local mods is
still on. Those switch conflicts aren't nice to get on 'svn update'. But
still need to think about allowing the conflicts if user wants them.

This adds status-crawls during update, but only on each dir external
definition for which the URL mismatches the current BASE node.

~Neels

On 09/02/2011 11:51 PM, Neels J Hofmeyr wrote:
> Added issue #4005 (got some response on IRC).
> 
> ~Neels
> 
> On 09/01/2011 11:34 PM, Neels J Hofmeyr wrote:
>> An svn:externals dir, first checked out onto an already versioned target dir
>> (during update), blows away local modifications.
>>
> [...]
> 

Re: dir external can blast away local mods

[Neels J Hofmeyr <ne...@elego.de>]

Added issue #4005 (got some response on IRC).

~Neels

On 09/01/2011 11:34 PM, Neels J Hofmeyr wrote:
> An svn:externals dir, first checked out onto an already versioned target dir
> (during update), blows away local modifications.
>
[...]