Hi, Just as this might be interesting to some people I thought I'd post here, further information will go into the wiki (probably an extended version of this mail). base-line: My win32 port is now mostly functional. For sources, see my archive at http://johannes.sipsolutions.de/archives/address@hidden, grab dists--jmb--1.0 and then build-config sipsolutions.de/win32.tla That will grab the following branches: hackerlab--win32--1.0 tla--win32--1.2 package-framework--win32--1.0 Also, you must get my modified tar code that now supports long filenames, which is tar--win32--1.12 That is a modified version of the code found in the CVS of unxutils.sf.net, which uses path-mangling (with \\?\) to support long filenames. You then have to install that tar as tar.real.exe, and the tar-wrapper that is found in the tla tree as tar.exe. I plan to change this (making that tar.exe and tar-wrapper.exe) and also provide a binary distribution. In any case, the following is currently supported: * basic operation (commit, get, update, etc) * revision libraries * local archives (or via shared drive (samba works)) * remote archives via ftp * probably more that I haven't tested yet not working (for me) * http access to archives untested * sftp access to archives (might work with putty or some other ssh?) * gpg verification (I currently have a `true' program as the verify script * gpg signing of archives probably never supported * symlinks (actually, archives with symlinks currently break it all) [though it _could_ actually supported if we patch all the tools...] * proper file permissions other than readonly/not readonly * scripts for signing rules, hooks etc, I might provide a helper program some day though. current quirks * need to edit the log-file with an editor that creates unix newlines, no CRLF accepted * lots of FIXME output (vu_sys_chmod needs to be revised) * tilde-expansion doesn't really work (commented out mostly) * you need to have HOME set (zsh does this automatically I think) * sometimes leaves temporary files behind in your $TEMP directory (not sure why though) behaviour differing from the standard tla * would use output of verify rule as checksum data, so gpg could conceivably work. * proftpd fixes from my archives are in here (I use proftpd) * should get some more of my fixes real soon now, and maybe also log template support runtime requirements: * Win2k+ (I think XP home should work just as well as XP Pro) - untested on NT4, but since my parents still have a NT4 machine I might test this some day, it _should_ work though (specifically, hardlink-support is built-in if you have enough privileges) * NTFS drive for the tree and the revision library, otherwise you'll probably run into errors * definitely doesn't work on 95/98/me due to unicode and NTFS * msvcrt (microsoft visual C runtime) * a shell to use it ;-) build requirements: * only tested with mingw32 cross compiler * standard tools on linux -> refer to the wiki page `UsingJohannesPort' other recommendations: * look for HardLinkShellExt -- an explorer add-in that allows you to create and view hardlinks (beware: only works correctly in "explore" mode) * don't use `tla get --link', there's probably no editor that will break links * use zsh.exe instead of cmd.exe (from unxutils) Use with care. If you have problems with inode signatures, send them to me. I am currently using some information as the `inode' number of a file of which the API documentation says that it changes when you reboot or close the file, but it has never changed for me so far. Therefore, I am inclined to assume that NTFS actually uses that value internally and we can treat it just like an inode number. Will search some hints if that is true or not, expertise and experience is welcome :) Unfortunately its quite slow. All the file name mangling for each access to the file system is slow, and the file-system appears to be pretty slow as well compared to linux. Anyway, thats all about this for now. johannes -- http://www.sipsolutions.de/ Key-ID: 9AB78CA5 Johannes Martin Berg <address@hidden>
Attachment:
signature.asc
Description: This is a digitally signed message part