From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14437 invoked by alias); 16 Oct 2009 09:44:09 -0000 Received: (qmail 14276 invoked by uid 22791); 16 Oct 2009 09:44:07 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Oct 2009 09:44:03 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id D19382F7802D; Fri, 16 Oct 2009 10:44:00 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs7lpZRnnppi; Fri, 16 Oct 2009 10:43:58 +0100 (BST) Message-ID: <4AD8405D.1010205@ecoscentric.com> Date: Fri, 16 Oct 2009 09:44:00 -0000 From: Alex Schuilenburg User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Larmour CC: ecos-maintainers@ecos.sourceware.org Subject: Re: hg conversion notes and summary References: <4AD32231.5060506@ecoscentric.com> <4AD5E3C1.10700@ecoscentric.com> <4AD7F4D3.6010008@jifvik.org> In-Reply-To: <4AD7F4D3.6010008@jifvik.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2009-10/txt/msg00003.txt.bz2 Jonathan Larmour wrote on 2009-10-16 05:21: > Alex Schuilenburg wrote: >> FWIW, 261 sites cloned http://hg-pub.ecoscentric.com/ecos/ or downloaded >> eCos from hg in the first 48 hours from the first public download. Not >> quite firefox or linux standards, but then we are not talking about a >> consumer item (the source, that is). I was quite pleasantly surprised >> by the number and apparent level of interest. It is a good argument >> against anyone who thinks eCos is dead. > > I confess to also being (pleasantly!) surprised by that number. Of > course that doesn't necessarily mean they're using hg rather than > importing into a different DRCS, although that's probably more likely. Unfortunately a typo on my part has meant I have accidentally overwritten the logs so I cannot figure out what the split was between browser and hg. All the current ones since the images update however are browser accesses - and a surprising number of OS X users!?! > > >> It also raised something I did not think about. As people look like >> they are using the repo already, there is a good argument for also >> providing patches through the mechanisms hg provides. I would be >> interested to know whether you are still sticking with email, or whether >> you intend to start using bugzilla, since I could start work on a >> template to give you maintainers some idea of what support you should >> expect from your DRCS in the provision of patches and contributions. hg >> has both email and bugzilla support, BTW :-) > > We're currently involved in some other discussions. There's a good > chance we might want to get back to you about some bugzilla munging if > you don't mind, so please do hold the thought. OK. Also, you may notice over the next week or so that I am upgrading bugzilla to 3.4.2. There will be a new look to the website but basically it will remain stock Bugzilla. > > >> I would also look to preserve the changeset IDs if you were to convert >> from hg to git, or if you chose hg, clone rather than export/import, so >> as not to inconvenience those who have already started using the repo. > > If that doesn't have any drawbacks I don't see why not. None. You can reset the parent link once you have cloned, if using hg, but I am not sure how to preserve the ids within git. I believe the best method to preserve the IDs through to git would be for me to push the repo using the hg-git plugin, but have yet to test whether this actually preserves the IDs or just does a mapping between git and hg IDs. > > >> As an aside, I am glad people are finding it useful - makes my efforts >> worthwhile and feel appreciated. Even more, I am very pleased our small >> Dell SC1425 did not appear to blink - hgwebdir.cgi is better than I >> thought :-) > > As a matter of interest, what version of hg are you using? sourceware > claims to be running "5c95d7667dd1" presumably because it's a custom > build, but I have no idea how to compare that with what you may be > using. I note the file dates are Nov 7 2008 though, for what that's worth. We are using the official 1.3.1 release (3ef6c14a1e8e), and it looks like sourceware is running straight from the hg repo out of the stable branch, somewhere between 1.0 and 1.0.2 release going from the changeset id http://selenic.com/repo/hg-stable/rev/5c95d7667dd1. The 1.3.1 release is Jul 22 2009, http://selenic.com/repo/hg-stable/rev/3ef6c14a1e8e So it is apparently not a custom build and a "hg pull -u -r 3ef6c14a1e8e" or "hg pull -u -r 1.3.1" will get you there. Given that I built 1.3.1 on RH 7.2, I would be very surprised if you had any building issues. The only requirement is python 2.4 or above, which again I built for RH7.2 with an openssl and bsddb update as well. No issues, other than having to mess with the usual configure nonsense for local installations so as not to touch the existing openssl and bsddb installations since the RH 7.2 machine is a critical release machine of ours. You may also encounter dependencies on asciidoc and xmlto needing to be installed as well if you wish to build the hg documentation and book, but I would be surprised if sourceware did not already have those installed. I did not bother with those on our RH7.2 box. > I also see an hgext dir with the same date, including bugzilla.py, > notify.py. > > If we do make a decision to move to hg, we'll need to know if there > would be any problems using that version, and so whether I'd need to > agitate towards moving sourceware to something more recent (which > isn't straightforward as other projects use hg too). It would be worthwhile upgrading IMHO to pick up the current features and fixes - the only requirement is python 2.4 or above. There are no problems I know of upgrading - I upgraded from 1.0.2 to 1.3.1 midway through our internal CVS to hg conversion and in fact benefited from one of the bugfixes (hg reports a file as modified when it is not - simple to recover, but annoying when you do a major merge), but it does not matter really what sourceware is running if it is only handling push/pull since I would assume any merge work would be done offsite on sombody's own machine and their own updated version of hg. That after all is what DRCS is all about ;-) The only local sourceware issues may be bugzilla, notify or the hgwebdir.cgi which have seen fairly useful improvements since 1.0 (including git plugin and git views so those got fans still get the same look and feel, should you be so inclined). -- Alex Schuilenburg Managing Director/CEO eCosCentric Limited www.ecoscentric.com