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

Potential issue with svn:externals

From: Thomas Giesel <skoe_at_directbox.com>
Date: Tue, 15 Jun 2010 09:50:36

Hi all,

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

The main question is if you agree wether I should file a bug about this.

Let's start 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 .

>>>>>>>>>>>>>>>
 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. (empty lines removed from output)

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 looks inconsistent to me:

>>>>>>>>>>>>>>>
 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.

btw: Subversive even shows "src/d" as normal external in the project
explorer after these two lines have been removed, while "b" is shown
with an exclamation mark (Obstructed). "src/d" can't be removed with
Eclipse then, one has to "rm -r" it manually from a shell window.

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. Hopefully this feature will
get even better in the future ;)

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

Regards,
Thomas
Received on 2010-06-15 09:51:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.