Re: Dia on git.gnome.org (experimental repository)



On Sun, Jan 18, 2009 at 6:20 PM, Owen Taylor <otaylor redhat com> 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)
>>
>> hb HB-T1XP /d/devel/from-git
>> $ git --version
>> git version 1.5.4.2.1161.g1a6f0
>>
>> hb HB-T1XP /d/devel/from-git
>> $ git clone ssh://hans git gnome org/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://hans git gnome org/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 hans master gnome org' work in the same terminal? If not,
> ssh -v may be informative.

I think this should be  'ssh hans git gnome org'.
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.
>
>> hb 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://USERNAME git gnome org/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?

Simos

>> Probably I'm just doing something stupid with the URLs, because my cairo
>> clone still seems to work with the same git version.
>>
>> hb 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 <hans src gnome org>
>> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]