Hi Dscho et al, I've been using git on Windows since many months by now and I love it. As I've read on http://article.gmane.org/gmane.comp.version-control.msysgit/1421 and following, git-svn doesn't yet work on Msys mostly because the perl bindings and its requires modules are not built correctly. I'd like to work on this - I've ported applications to windows/mingw way too long by now anyway... (and after i18n, now git-svn is the very last puzzle piece that I need to convince all my workplace to switch to git)
As for your question in that message why the libsvn_* are not built dynamically: I'm not so sure how familiar you are with building DLLs on mingw + autotools + libtool. For the archives I'll add the full explanation according to my current knowledge: So far I can only say this is due to an erroneous (or: not up-to-date) build system in the subversion-1.4.6 and subversion-deps-1.4.6 tarball. In order to have any library built dynamically on Windows/mingw, an autotools + libtool buildsystem requires two prerequisites: The configure.in must contain the two lines AC_LIBTOOL_WIN32_DLL AC_LIBTOOL_RC before the AC_PROG_LIBTOOL macro, and additionally at every lib_LTLIBRARY target the additional LDFLAGS=-no-undefined must be present. The latter one is easy - I just run "make LDFLAGS=-no-undefined". But for the first: In the two svn-1.4.6 tarballs, those macros are are missing in configure.in, hence the shipped libtool will be configured so that it refuses to build shared libraries on mingw. This results in the fact that each configure run will print the message configure:11292: checking if libtool supports shared libraries configure:11294: result: no configure:11297: checking whether to build shared libraries configure:11318: result: no configure:11321: checking whether to build static libraries configure:11325: result: yes regardless of whether or not you gave the option --enable-shared --disable-static to ./configure. That sucks. The only way to get rid of this is to re-build configure after these two macros have been added to configure.in, i.e. in effect rebuilding the whole build system as if we had obtained a clean svn checkout of svn (no pun intended). I tried this here and there and I was able to have a apr/.libs/libapr-0-0.dll built and also neon/src/.libs/libneon-25.dll, but eventually libtool decided to not build shared libraries anymore. Maybe in apr/ there were some complaints that some symbols were indeed undefined - if this can't be fixed easily, it would indeed mean that libapr-0-0.dll cannot be built as a valid DLL. Whatever. Eventually I screwed up my build tree and I can't get the subversion directory to reconfigure. I'll continue trying. It might be necessary to update your installed versions of autoconf, automake, libtool. Question: I obtained a git-clone of msysgit.git. How would you propose to proceed from there? In particular, which commands am I supposed to run in the newly started msys window in order to download, compile, and install git in that msys environment? Currently I use git from a different msys installation, but I guess for msysgit I should use the one from msysgit.git. Cheers, Christian
