diff options
Diffstat (limited to 'doc/design/assistant')
7 files changed, 119 insertions, 4 deletions
diff --git a/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_1_0b4a6e4893b0157e4768b46468dbbb87._comment b/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_1_0b4a6e4893b0157e4768b46468dbbb87._comment new file mode 100644 index 000000000..9e1f666aa --- /dev/null +++ b/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_1_0b4a6e4893b0157e4768b46468dbbb87._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkGCmVc5qIJaQQgG82Hc5zzBdAVdhe2JEM" + nickname="Bruno" + subject="comment 1" + date="2013-05-10T23:52:43Z" + content=""" +I have a 'Connection timed out' when I try to set-up my Gtalk account on my Nexus 4 (4.2.2). I tested it at home without a web proxy. + +Here's a screen capture: [http://i.imgur.com/RBcNjSv.png](http://i.imgur.com/RBcNjSv.png). +"""]] diff --git a/doc/design/assistant/blog/day_260__Windows_dev_environment.mdwn b/doc/design/assistant/blog/day_260__Windows_dev_environment.mdwn new file mode 100644 index 000000000..4fa2ccf5a --- /dev/null +++ b/doc/design/assistant/blog/day_260__Windows_dev_environment.mdwn @@ -0,0 +1,46 @@ +Set up my Windows development environment. For future reference, I've +installed: + +* haskell platform for windows +* cygwin +* gcc and a full C toolchain in cygwin +* git from upstream (probably git-annex will use this) +* git in cygwin (the other git was not visible inside cygwin) +* vim in cygwin +* vim from upstream, as the cygwin vim is not very pleasant to use +* openssh in cygwin (seems to be missing a ssh server) +* rsync in cygwin +* Everything that `cabal install git-annex` is able to install successfully. + This includes all the libraries needed to build regular git-annex, + but not the webapp. Good start though. + +Result basically feels like a linux system that can't decide which way +slashes in paths go. :P I've never used Cygwin before (I last used a +Windows machine in 2003 for that matter), and it's a fairly impressive hack. + +---- + +Fixed up git-annex's configure program to run on Windows (or, at least, in +Cygwin), and have started getting git-annex to build. + +For now, I'm mostly stubbing out functions that use unix stuff. Gotten the +first 44 of 300 source files to build this way. + +Once I get it to build, if only with stubs, I'll have a good +idea about all the things I need to find Windows equivilants of. +Hopefully most of it will be provided by +<http://hackage.haskell.org/package/unix-compat-0.3.0.1>. + +---- + +So that's the plan. There is a possible shortcut, rather than doing a full +port. It seems like it would probably not be too hard to rebuild ghc inside +Cygwin, and the resulting ghc would probably have a full POSIX emulation +layer going through cygwin. From ghc's documentation, it looks like that's +how ghc used to be built at some point in the past, so it would probably +not be too hard to build it that way. With such a cygwin ghc, git-annex +would probably build with little or no changes. However, it would be a +git-annex targeting Cygwin, and not really a native Windows port. So +it'd see Cygwin's emulated POSIX filesystem paths, etc. That +seems probably not ideal for most windows users.. but if I get really stuck +I may go back and try this method. diff --git a/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn b/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn new file mode 100644 index 000000000..8107336f0 --- /dev/null +++ b/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn @@ -0,0 +1,29 @@ +After working on it all day, git-annex now builds on Windows! + +Even better, `git annex init` works. So does `git annex status`, and +probably more. Not `git annex add` yet, so I wasn't able to try much more. + +I didn't have to add many stubs today, either. Many of the missing Windows +features were only used in code paths that made git-annex faster, but I +could fall back to a slower code path on Windows. + +The things that are most problimatic so far: + +* POSIX file locking. This is used in git-annex in several places to + make it safe when multiple git-annex processes are running. I put in + really horrible dotfile type locking in the Windows code paths, but I + don't trust it at all of course. +* There is, apparently, no way to set an environment variable in Windows + from Haskell. It is only possible to set up a new process' environment + before starting it. Luckily most of the really crucial environment + variable stuff in git-annex is of this latter sort, but there were + a few places I had to stub out code that tries to manipulate git-annex's + own environment. + +The `windows` branch has a diff of 2089 lines. It add 88 ifdefs to the code +base. Only 12 functions are stubbed out on Windows. This could be so much +worse. + +Next step: Get the test suite to build. Currently ifdefed out because it +uses some stuff like `setEnv` and `changeWorkingDirectory` that I don't know +how to do in Windows yet. diff --git a/doc/design/assistant/blog/day_262__DOS_path_separators.mdwn b/doc/design/assistant/blog/day_262__DOS_path_separators.mdwn new file mode 100644 index 000000000..a7f6c07cc --- /dev/null +++ b/doc/design/assistant/blog/day_262__DOS_path_separators.mdwn @@ -0,0 +1,14 @@ +It's remarkable that a bad decision made in 1982 can cause me to waste an +entire day in 2013. Yes, `/` vs `\` fun time. Even though I long ago +converted git-annex to use the haskell `</>` operator wherever it builds +up paths (which transparently handles either type of separator), I still +spent most of today dealing with it. Including some libraries I use that +get it wrong. Adding to the fun is that git uses `/` internally, even on +Windows, so Windows separated paths have to be converted when being fed +into git. + +Anyway, `git annex add` now works on Windows. So does `git annex find`, +and `git annex whereis`, and probably most query stuff. + +Today was very un-fun and left me with a splitting headache, so I will +certainly *not* be working on the Windows port tomorrow. diff --git a/doc/design/assistant/blog/day_262__DOS_path_separators/comment_1_45ecae90b22e31202c21083980d6b567._comment b/doc/design/assistant/blog/day_262__DOS_path_separators/comment_1_45ecae90b22e31202c21083980d6b567._comment new file mode 100644 index 000000000..a024103a7 --- /dev/null +++ b/doc/design/assistant/blog/day_262__DOS_path_separators/comment_1_45ecae90b22e31202c21083980d6b567._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://jamesjustjames.wordpress.com/" + nickname="purpleidea" + subject="Isn't windows deprecated?" + date="2013-05-13T05:51:20Z" + content=""" +I feel bad for you, however I respect you for keeping your promise to try and hack on Windows. I had to port over some code than ran beautifully on GNU/Linux and it was more trouble than it was worth. In the end it was never used :P + +Cheers! +"""]] diff --git a/doc/design/assistant/blog/day_262__catching_up.mdwn b/doc/design/assistant/blog/day_262__catching_up.mdwn new file mode 100644 index 000000000..8158a34c6 --- /dev/null +++ b/doc/design/assistant/blog/day_262__catching_up.mdwn @@ -0,0 +1,9 @@ +Spent some time today to get caught up on bug reports and website traffic. +Fixed a few things. + +Did end up working on Windows for a while too. I got `git annex drop` +working. But nothing that moves content quite works yet.. + +I've run into a stumbling block with `rsync`. It thinks that +`C:\repo` is a path on a ssh server named "C". Seems I will need to translate +native windows paths to unix-style paths when running rsync. diff --git a/doc/design/assistant/windows.mdwn b/doc/design/assistant/windows.mdwn index 26ff2c1c6..78ab69feb 100644 --- a/doc/design/assistant/windows.mdwn +++ b/doc/design/assistant/windows.mdwn @@ -8,10 +8,7 @@ Stackoverflow has some details. NTFS supports symbolic links two different ways: an [[!wikipedia NTFS symbolic link]] and an [[!wikipedia NTFS_junction_point]]. The former seems like the closest analogue to POSIX symlinks. -Make git use them, as it (apparently) does not yet. - -Currently, on Windows, git checks out symlinks as files containing the symlink -target as their contents. +The windows port will not use symlinks. It will only support direct mode. ## POSIX |