On Sun, Jan 18, 2009 at 7:14 PM, Simos Xenitellis <[email protected]> wrote: > On Sun, Jan 18, 2009 at 6:20 PM, Owen Taylor <[email protected]> wrote: >> On Sun, 2009-01-18 at 18:02 +0100, Hans Breuer wrote: >>> As the current maintainer of Dia I finally got around to check the >>> experimental git repository, unfortuantely without much success. >>> >>> My first attempt was a checkout (clone) for my main development platform >>> (winxp, please don't shoot me;)) but after failing that I took a look form >>> Linux as well. >>> >>> My main question at the moment is (could not find an answer on >>> gnome-infrastructure thread [0] or http://live.gnome.org/GitMigration) : >>> >>> Will it be possible for a module maintainer on gnome.org to choose to stay >>> with SVN? >> >> I don't think that's practical. There's a lot of infrastructure >> involved; the commit mail, web interface, etc that interact with the >> version control system. Supporting multiple different version control >> systems long-term would strain an already under-resourced sysadmin team. >> >>> Git from win32 >>> ============== >>> neither named nor anonymous cloning did work for me (works fine from Linux) >>> >>> h...@hb-t1xp /d/devel/from-git >>> $ git --version >>> git version 1.5.4.2.1161.g1a6f0 >>> >>> h...@hb-t1xp /d/devel/from-git >>> $ git clone ssh://[email protected]/git/dia.git dia >>> Initialized empty Git repository in d:/devel/from-git/dia/.git/ >>> Permission denied (publickey). >>> fatal: The remote end hung up unexpectedly >>> fetch-pack from 'ssh://[email protected]/git/dia.git' failed. >> >> This looks to me like something wrong with your ssh key setup on >> Windows. If you are using OpenSSH (the default for msysgit, for >> example), it will be looking for the files in ~/.ssh/ unix-style, while >> with tortoise-svn you would likely be using putty, which handles keys >> different. >> >> (You can get msysgit to use plink.exe from the putty distribution >> instead, though there are some weirdness there that I haven't quite >> figured out.) >> >> Though there is a smaller possibility that somehow the windows ssh setup >> is breaking how we restrict the ssh command execution on git.gnome.org >> (I can't really test this since my ssh commands there aren't >> restricted...) But I wouldn't expect the error above if that was the >> case. >> >> Does 'ssh [email protected]' work in the same terminal? If not, >> ssh -v may be informative. > > I think this should be 'ssh [email protected]'. > When trying SSH to master.gnome.org, it appears that it does not have > the public keys (it asks for a password). > >> Cloning dia via ssh works for me though the repository is larger and >> slower to checkout than expected: >> >> $ du -hs /mnt/git-data/svn/{dia,gtk+} /git/{dia,gtk+}.git >> 150M /mnt/git-data/svn/dia >> 1.2G /mnt/git-data/svn/gtk+ >> 114M /git/dia.git >> 88M /git/gtk+.git >> >> It could be that because the conversion failed partway dia didn't get >> repacked at the end. >> >>> h...@hb-t1xp /d/devel/from-git >>> $ git clone git://git.gnome.org/dia dia >>> Initialized empty Git repository in d:/devel/from-git/dia/.git/ >>> git.gnome.org[0: 209.132.176.202]: errno=No such file or directory >>> fatal: unable to connect a socket (No such file or directory) >>> fetch-pack from 'git://git.gnome.org/dia' failed. >> >> Somehow xinetd had stopped taking connections on the git part. >> Restarting it fixed. I'll keep an eye on that. > > When trying now, the error message is > > $ git clone ssh://[email protected]/gucharmap gucharmap > Initialized empty Git repository in /tmp/gucharmap/.git/ > fatal: '/gucharmap': unable to chdir or not a git archive > fatal: The remote end hung up unexpectedly > $ _ > > Is this an issue with absolute paths? That is, git tries to access > '/gucharmap' which of course does not exist. > Should there be a /git link on git.gnome.org that points to the > directory that has the actual repositories?
And replying to myself, there is already such a /git link, so the URL for SSH clones is git clone ssh://[email protected]/git/gucharmap gucharmap Simos > Simos > >>> Probably I'm just doing something stupid with the URLs, because my cairo >>> clone still seems to work with the same git version. >>> >>> h...@hb-t1xp /d/devel/from-git >>> $ git clone git://anongit.freedesktop.org/git/cairo cairo.2nd >>> Initialized empty Git repository in d:/devel/from-git/cairo.2nd/.git/ >>> remote: Counting objects: 40543, done.←[K >>> remote: Compressing objects: 100% (10625/10625), done.←[K >>> remote: Total 40543 (delta 30263), reused 40097 (delta 29878)←[K >>> Receiving objects: 100% (40543/40543), 26.84 MiB | 230 KiB/s, done. >>> Resolving deltas: 100% (30263/30263), done. >>> Checking out files: 100% (1595/1595), done. >>> >>> Conversion errors >>> ================= >>> Looking at http://git.gnome.org/cgit/dia/ it appears to me that the >>> dia/trunk is not available at all. I assume it should have been mapped >>> to 'master', but there the last change is 7 month old regardless of >>> quite some activity in Dia trunk since than. >>> >>> The last commit shown on master is: >>> >>> commit 7fee0d296dc5d674dcf405ee722f32ae67c638f2 >>> Author: Hans Breuer <[email protected]> >>> Date: Sun Jun 29 16:08:33 2008 +0000 >>> >>> [Patch from Thomas Harding fixing help generation for non-gnome case] >>> without gnome install to $(helpdocdir) initialize HAVE_XSLTPROC >>> conditionalize on HAVE_GNOME >>> >>> svn path=/trunk/; revision=4079 >>> >>> The SVN action apparently breaking the conversion was: >>> >>> Revision: 4080 >>> Author: hans >>> Date: 18:43:49, Sonntag, 29. Juni 2008 >>> Message: >>> Copied remotely >>> ---- >>> Added : /branches/dia-0-90(Copy from path: /tags/dia_0_90, Revision, 4079 >> >> OK, we'll add this to the list of problems we need to investigate. It's >> not too surprising that the tool choked on branching from a tag; it's >> not exactly a common operation. >> >>> Choosing the right vcs? >>> ======================= >>> In an earlier post Owen was mentioning a lot of "angst" [1] regarding the >>> switch from SVN to git, unfortunately I share that angst. >>> >>> In the list of possible (distributed) version control systems from my >>> limited experience git is the one, which cares less for portability (fair >>> enough for being the Linux kernel version control system). >>> >>> But for gnome.org where a lot of projects actually do care for portability >>> I think there should be official vcs support at least for major platforms >>> we care about. And some usable gui integration would be nice, too [2]. >> >> Certainly the cross-platform story for git isn't perfect, but I think it >> will just get better: >> >> - msysgit is very easy to install, if not that easy to use for non-Unix >> users. >> >> - Some initial tortoisegit code exist. I don't know if it is at all >> usable. >> >> - There is fairly active work on 'libgit2' - making the internals of >> git into a library, which has the potential to make a native git >> on windows without cygwin more practical. >> >> - Owen > _______________________________________________ Gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
