[SVN-3662] Inconsistent status report of svn:externals on directory levels > 1

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.6.x
• Fix Version/s: 1.7.0
• Component/s: cmdline client

Environment

Linux

• Assignee: Unassigned
• Reporter: Subversion Importer
• Created: 23/Jun/10 07:29
• Updated: 27/Oct/18 16:28
• Resolved: 21/Jan/13 16:08

Description

There's an issue with svn:externals when using them on subdirectories, which 
should be fine according to the documentation.

Let's look at an example with these svn:externals:

^/tags/libs/a/1.0   a
^/tags/libs/b/2.0   b
^/tags/apps/c/1.1   src/c
^/tags/apps/d/2.0   src/d

svn up .
svn st .

(empty lines removed from output)
>>>>>>>>>>>>>>>
 M      .
X       a
X       b
X       src
Performing status on external item at 'a'
Performing status on external item at 'b'
Performing status on external item at 'src/c'
Performing status on external item at 'src/d'
<<<<<<<<<<<<<<<

This look okay so far, even if "X src/c" and "X  src/d" would be better IMHO, 
since "src" was created implicitely and is not really a direct external. (This 
was already mentioned in issue 2638)

Now let's remove two of these lines, the rest looks like this:

^/tags/libs/a/1.0 a
^/tags/apps/c/1.1 src/c

svn up .
svn st .

Results in output which is inconsistent:

>>>>>>>>>>>>>>>
 M      .
X       a
?       b
X       src
Performing status on external item at 'a'
Performing status on external item at 'src/c'
<<<<<<<<<<<<<<<

The directory src/d remains unchanged on my hard disk and does not get any 
comment on "svn st". I would expect something like "?  src/d" like is is 
printed for the directory "b".

This may be dangerous if people use 
"svn ps svn:externals -F <predefd-externals> ." and don't check
carefully for removed entries.

I tried to get a second opinion on the mailing list and IRC, but nobody could 
give helpful information.

Our software has many different configurations with different versions of 
different subsystems, this can be done easily with externals, better than using 
branches for all variations.

(Server: >= 1.6.x, Client: 1.6.11, both on Linux)

Original issue reported by skoe

Issue Links

• depends upon: SVN-3351 can't remove file externals
• depends upon: SVN-3530 changing external's URL is broken in trunk
• depends upon: SVN-2667 Please add www.StatSvn.org to the links page
• is blocked by: SVN-3351 can't remove file externals
• is blocked by: SVN-3530 changing external's URL is broken in trunk
• is blocked by: SVN-2667 Please add www.StatSvn.org to the links page