On 25.09.2012 22:14, Barton Wright wrote:
> 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.
>
> ·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/.
>
> 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.
If you use the check-for-modifications dialog on such a symlink folder,
you can see that Subversion reports its status as "obstructed". And that
status also has the same overlay as "conflicted" because it usually
means that you have to take action to resolve the problem.
obstructed means
"versioned item obstructed by some item of a different kind"
you also get that status (example) if you have a file named "test" and
an update wants to add a folder named "test" instead.
So usually, that's a serious problem and the "conflict" overlay is
therefore shown.
No idea on how to better handle this.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3010470
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-09-26 21:49:53 CEST