[darcs-users] Re: windows (was: Subversion vs DARCS...)

David Roundy droundy at jdj5.mit.edu
Mon Jul 7 16:10:25 UTC 2003


ccing mnet, just to let them know we do seem to have a win32 port
semi-in-the-works.

On Mon, Jul 07, 2003 at 05:45:03PM +0200, Peter Strand wrote:
> On Mon, Jul 07, 2003 at 06:59:18AM -0400, David Roundy wrote:
> > One thing that occurred to me that you might not have considered is that
> > darcs hasn't been ported to windows.  I took a look at mnet but didn't
> > immediately see if it ran on windows.  Darcs could certainly be ported to
> > windows (and maybe even without too much work), but I'm not going to do it,
> > as I don't have windows.
> 
> I got darcs to run on windows (only pull-mode, so far),
> but I haven't tested it very much yet..
> 
> There was basically two problem areas, posix-stuff and line-endings.
> 
>  [posix]
>   Filestat and time functions are easily wrapped, as windows does
>   have the relevant functions (time, _stat and _utime)

Good.

>   I used the system function and shell redirections instead of
>   pipes, as they are different in windows (and not available in ghc).
>  
>   hscurl.c is filled with unixy stuff ;)
>    so I didn't use it and wrote support for external fetch-commands
>    instead, like wget and curl (and scp!), by letting them download
>    to temporary files which are then read.
>    (this also avoids the need for libcurl and pthreads, which are 
>     available on windows but I feared problems in that area..)

Sounds reasonable.  I like the threaded libcurl stuff, but support for
external commands is definitely a good idea.

>  [line-endings]
>   Windows uses "\r\n" as instead of a single '\n', this confuses darcs
>   when files are moved between systems. 
> 
>   The simplest solution I could think of was to convert files to the
>   local convention when they are fetched from a remote system. It seems
>   to be enough (for pull), but I have not tested it very thoroughly.
> 
>   Is there a better way?

This is basically what I had planned.  Since darcs internally views a text
file as a list of lines, as long as the file is read in properly it can do
its diffs all right, and as long as it writes according to the proper
convention, everything should be fine.  I think we should actually make the
text file parsing robust with respect to these issues... this could be done
by simply filtering out all '\r's in the file, for example.  That might
cause problems on the mac where the lines end with '\r' only, or at least
used to...

The patch parsing code should be robust with respect to either "\r\n", "\n"
or mixed line endings.  I suspect it isn't robust in this respect, but
consider that a bug and will be willing to work to fix it.

> I can make the repository with these changes available if anyone is
> interested in it..

I am most interested!  :)

> As mentioned above, I haven't done anything related to pushing patches.
> I don't know what the windows-counterpart to /usr/sbin/sendmail is,
> probably some obscure library... ;)

Hmmmm.  Would definitely be nice to figure out.  It can't be too hard.
Perhaps we could even add a feature to push a set of patches to everyone on
your addressbook!  :)

> Using cygwin would probably make a couple of things easier, but native
> windows support didn't seem very difficult and a nice thing to have..

Yeah, native windows support sounds wonderful!

> And I found the ability to use ssh as transport very useful, also under
> linux, as it removes the need for a webserver (or nfs-mounted
> directories) when syncing between computers.  Having a somewhat generic
> mechanism for using external file-fetching commands would be a useful
> addition in general, I think..  (semiautomatically support wget, curl,
> scp, rsync, rcp, ncftpget, whatever..)

I agree.  I'll take a look at your code and think about how to best support
external commands.  I imagine putting something in _darcs/prefs to link a
command with a URL type.  However, this is really something that should be
configured on a per-computer basis rather than a per-repository basis.  I
may have to bite the bullet and set up support for a ~/.darcs configuration
file (or directory).
-- 
David Roundy
http://civet.berkeley.edu/droundy/




More information about the darcs-users mailing list