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

TortoiseSVN handles Externals incorrectly when a folder structure (i.e. folder/sub-folder) instead of a single folder is supplied as local path

From: Christian Balzer <christian.balzer.ba_at_gmail.com>
Date: Thu, 17 Apr 2014 14:49:03 +0100

Hi!

I have set up externals and witnessed TortoiseSVN display some
behavior that I consider strange; I think it might be a bug.

I work on a (work) project that's scattered across a myriad of
(source) projects and SVN locations. To make life easier, I followed a
colleague's advice and set up a new folder on SVN, /_all/, and
specified all of the other projects' trunk folders as externals. The
svn:externals property window looked a bit like this:
Path | URL | Peg | ...
project1/trunk | ^/project1/trunk | 1234 |
groupA/subgroup1/project2/trunk | ^/groupA/subgroup1/project2/trunk | 1234 |
project3 | ^/project3 | 1234 |

As you can see, it was about being able to check all trunks out
together, not so much about changing folder structures. In particular,
I used relative paths for the local paths...

A screenshot can be found here: http://i.stack.imgur.com/pnkEo.png

When I check /_all out, it dutifully pulls out all external projects,
and puts them in the right locations. It works great.

But in my SVN Repo Browser, I can only see one of all those externals
being linked in: project3. It also seems to have the wrong overlay
icon (blue instead of red
arrow:http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-repobrowser.html
) Incidentally, it's the one project where there is no trunk/
subfolder (or any other subfolder specified in the local path, for
that matter)...

A screenshot can be found here: http://i.stack.imgur.com/Pr8wx.png

On top of that, TortoiseSVN seems to be unsure what to make of it all;
only the one external project displayed in the Repository Browser
above is recognized as "up to date" (green tick), all others get a big
question mark assigned…

Screenshot here: http://i.stack.imgur.com/LkHgP.png

However, every file and folder under .../trunk/ has the right overlay
icons, e. g. pom.xml here:
(tick) _all / (?) groupA / (none) subgroup1 / (none) project2 / (none)
trunk / (tick) pom.xml

Initially I thought it might be down to me using the feature wrong,
and I raised a question on StackOverflow:
http://stackoverflow.com/questions/23131927/svn-externals-not-properly-displayed-in-tortoisesvns-repository-browser-and-loc

However, a colleague suggested I try not supplying a path (i.e.
folder/sub-folder/trunk) as the Local Path, but just a single folder,
as can be seen here:
http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/images/PropEditExternal.png

Path | URL | Peg | ...
aaaa | ^/service/groupB/aaaa/trunk | 1234
bbbb | ^/service/groupB/bbbb/trunk | 1234
cccc | ^/service/groupB/cccc/trunk | 1234

That seems to work just fine.

However, I believe paths should be supported, because the field in the
dialogue box (cf. last screenshot) is called "Local path", but more
importantly because that's what is implied by
http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-externals.html

What I would thus expect is that in the Repo Browser, project1, groupA
and project3 all have a red arrow as an overlay icon, and that the
overlay icons locally are all green ticks as long as the files are up
to date, e.g. for the example above, it should look like so:
(tick) _all / (tick) groupA / (tick) subgroup1 / (tick) project2 /
(tick) trunk / (tick) pom.xml

Could somebody please let me know if that is indeed a bug, or if I
need to do things differently?

Kind regards,

Christian

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3076663

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-04-17 15:49:10 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.