Re: Dia on (experimental repository)

On Sun, Jan 18, 2009 at 7:14 PM, Simos Xenitellis
<simos lists googlemail com> wrote:
> 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?

And replying to myself, there is already such a /git link, so the URL
for SSH clones is

git clone ssh://USERNAME git gnome org/git/gucharmap gucharmap


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