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

TSvn 1.7.9 shows incorrect conflicted icon for non-versioned Win7 top-level WC folder

From: Barton Wright <bwright_at_streambase.com>
Date: Tue, 25 Sep 2012 20:14:46 +0000

Stefan, let me state quickly up front that this is NOT a request to have TortoiseSvn (or the underlying Subversion libraries) handle versioning for Windows symlinks themselves. I understand that that is a difficult problem to solve, and I, for one, do not see much value in the versioning of symlinks.

This complaint is about how TSvn 1.7.x displays icons for Windows symlinks that point to the containing, top-level folder for a Subversion working copy. As you know, the containing, top-level folder for a WC is not itself versioned, and can be renamed or moved at will without breaking anything.

Here is the situation: our build system has a recent requirement that the source for two of our product lines be checked out into sibling folders with the exact names "streambase" and "liveview". Yet previous branches of our build system did not have the exact name requirement, and some of our engineers came up with personal command-line navigation systems (such as a set of Bash aliases) that used a private set of WC folder names based on each branch's internal project name. Their Bash aliases work the same way at the Bash prompt on Linux and on Cygwin under Windows.

On Linux, it is easy to reconcile using the new required folder names by checking out WCs into folders with the required names, then creating a Linux symlink from private name to new name. This satisfies the required folder names, but our Bash aliases still navigate to the private folder names, and everything works as before.

On Windows 7, the problem is also easy to solve, and in the same way: we check out into the required folder names, then create a Windows symlink (using the mklink command), such that our private folder names point to the new required folder names. With this mechanism, we can use any Subversion client's commands, including TSvn, in the real folder or in the symlinked folder. Windows consider both folders to be identical.

Now, here is the problem:

* On a machine with all Subversion 1.6.x clients (TortoiseSVN 1.6.16, Cygwin svn 1.6.17, and so on), the icons for such symlinked top-level WC folders show up in Windows Explorer with the same icon, usually green, as the real folder pointed to.

[cid:image001.png_at_01CD9B32.A4EEB5B0]

* However, on a different machine with its own set of WC folders set up the same way as the machine above, but using all Subversion 1.7.x clients (TortoiseSVN 1.7.9, Cygwin svn 1.7.6, and so on), the icons for the symlinked top-level WC folders show as conflicted.

[cid:image002.png_at_01CD9B33.BDF17DD0]

Of course, the symlinked folders are not actually conflicted in any way. By the magic of symlinks, those folders contain exactly the same unconflicted contents as the folder they point to. The proof is that the exact same mechanism is handled correctly using TSvn 1.6.x.

I must therefore conclude that the display of icons is broken in TSvn 1.7.x for Win7 symlinks that point to top-level WC folders.

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].

image001.png
image002.png
Received on 2012-09-25 22:18: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.