Re: Dia on (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 :
>> Will it be possible for a module maintainer on 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
>> 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
> (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, 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:// dia
>> Initialized empty Git repository in d:/devel/from-git/dia/.git/
>>[0:]: errno=No such file or directory
>> fatal: unable to connect a socket (No such file or directory)
>> fetch-pack from 'git://' 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 that points to the
directory that has the actual repositories?


>> 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:// 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 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 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]