work around absNormPath not working on Windows

Seems I punted on this while porting before. This hack relies on DOS not
using / in filenames, it's effectively an alternate path separatr in at
least current versions of windows..

Utility/Path.hs

@@ -21,10 +21,10 @@ import Control.Applicative
 import Data.Char
 import qualified System.FilePath.Posix as Posix
 #else
-import qualified "MissingH" System.Path as MissingH
 import System.Posix.Files
 #endif
 
+import qualified "MissingH" System.Path as MissingH
 import Utility.Monad
 import Utility.UserInfo
 
@@ -34,15 +34,15 @@ import Utility.UserInfo
  -
  - On Unix, collapses and normalizes ".." etc in the path. May return Nothing
  - if the path cannot be normalized.
- -
- - MissingH's absNormPath does not work on Windows, so on Windows
- - no normalization is done.
  -}
 absNormPath :: FilePath -> FilePath -> Maybe FilePath
 #ifndef mingw32_HOST_OS
 absNormPath dir path = MissingH.absNormPath dir path
 #else
-absNormPath dir path = Just $ combine dir path
+absNormPath dir path = todos <$> MissingH.absNormPath (fromdos dir) (fromdos path)
+  where
+	fromdos = replace "\\" "/"
+	todos = replace "/" "\\"
 #endif
 
 {- Returns the parent directory of a path.

debian/changelog

@@ -28,6 +28,7 @@ git-annex (5.20140128) UNRELEASED; urgency=medium
     directories.
   * Windows: Fix deletion of repositories by test suite and webapp.
   * Windows: Test suite 100% passes again.
+  * Windows: Fix bug in symlink calculation code.
 
  -- Joey Hess <joeyh@debian.org>  Tue, 28 Jan 2014 13:57:19 -0400
 

doc/bugs/On_Windows_the_Comitted_Symlinks_are_not_Relative.mdwn

@@ -90,3 +90,13 @@ The output of `git log -p` for me:
     @@ -0,0 +1 @@
     +.git/annex/objects/5X/qQ/SHA256E-s19915186--c6dc288ec8a77404c0ebc22cbe9b4ec911103fd022c3ca74eec582604dff80a7.exe/SHA256E-s19915186--c6dc288ec8a77404c0ebc22cbe9b4ec911103fd022c3ca74eec582604dff80a7.exe
     \ No newline at end of file
+
+> [[fixed|done]] -- I didn't notice this before because it happened to do
+> the right thing if you cd'd into the subdir before adding the file there.
+>
+> WRT the slow down issue, I don't see how it could matter to git-annex on
+> Windows whether the symlinks point to the right place. It only looks at
+> the basename of the symlink target to get the key. If you have a
+> repository that behaves poorly, you can probably use --debug to see if
+> git-annex is calling some expensive series of git commands somehow.
+> --[[Joey]]