This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: hg conversion notes and summary

Jonathan Larmour wrote on 2009-10-16 05:21:
> Alex Schuilenburg wrote:
>> FWIW, 261 sites cloned 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
The 1.3.1 release is Jul 22 2009,

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

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,
> 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

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]