public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
* hg conversion notes and summary
@ 2009-10-12 12:34 Alex Schuilenburg
  2009-10-14 14:44 ` Alex Schuilenburg
  0 siblings, 1 reply; 7+ messages in thread
From: Alex Schuilenburg @ 2009-10-12 12:34 UTC (permalink / raw)
  To: ecos-maintainers

Hi

As per my message on ecos-discuss, here is a brief set of notes of my
conversion of anoncvs to hg.

Tags
====
First, since some of you may not be familiar with DRCS systems, a note
on tags.  Tags in DRCS systems reflect the state of the repository or
branch at a particular point in time.  They cover the *whole*
repository, not individual files as CVS does.  This can and does lead to
differences between what "revisions" of files are tagged in CVS and
those tagged in hg. 

As a simple example, since CVS tags are simply textual bookmarks of
specific file revisions, there is nothing stopping somebody in CVS
tagging the revisions of one set of files as <xxx_release>, making a
bunch of changes with commits to some of those files so changing the
revisions, and then tagging a second set of files as <xxx_release>. 
While you can do this in CVS, you cannot do this in hg because hg tags
apply to a single changeset only. 

Of course this is just a simple example. In actual fact there are
another two complicated instances of how our current usage of CVS
results in similar mismatches, but one is enough to prove my point. This
also happened in real life as both the ecos and ecos-net modules were
tagged at different times, with updates to files previously tagged
occurring before the second tag was made. So since tags in DRCS systems
are made against a single changeset, there is no clean correspondence
betwen CVS tags and DRCS tags, and in fact the normal conversion
processes to git/hg/bzr they do not even attempt to preserve tags.  I
have made a pretty reasonable guess, however.

Conversion Process Summary
=======================
_**_

   1. Create a copy of the CVS repository, remove modules file and munge
      directory structure in CVS repository to match that given by
      modules file.
      /Note: This step was necessary to bring in the ecos network
      packages into the main tree rather than as a separate checkout.
      Also, the //naming of a module 'ecos' to an existing directory
      'ecos' confused the heck out of cvsps, as well as some files
      having a revision tagged "ecos"./
      /
      /
   2. Use a modified cvsps to create a summary set of changes (i.e.
      without the actual patch changes).  This effectively creates sets
      of "atomic" checkins which can be used to match hg changesets.
      /Notes:
      /
         1. /patchsets are created by cvsps/
         2. /changsets are created by hg/
         3. /CVS checkins of a group of files or directories are not
            atomic - the times of the changes to files recorded by RCS
            by a single CVS commit often differ, sometimes by as much as
            12 minutes for large commits.
            /
         4. /All of CVS diff, cvsps diff and the standard diff are
            unable to cope with certain changes to binary files and
            either crash or create patches that cause patch to crash/
         5. /Some CVS log entries were not UTF8 and came from different
            character sets.  These needed special attention (e.g. Roland
            Ca<DF>ebohm, Daniel N<E9>ri, and the best one... soft spaces
            <A0>)
            /
         6. /CVS locking was broken at some point as I found an instance
            of a tag being performed midway during a checkin by another
            user.  The CVS history files confirms this.  Tag was made by
            jifl, checkin by gthomas.

            /
   3. Loop through all the patchsets using RCS to create updated or new
      files within the corresponding repository, or delete files from
      the repository, and commit according to the log patchset log

   4. Some patchsets were applicable to multiple branches.  That is,
      parts or all of some changes within the trunk or a branch
      propogated to other branches or the trunk.  Such propogations were
      restricted to direct descendants or ascendants. Thus, for every
      checkin, checks were made to ensure that changes made in one
      branch/trunk were propogated when necessary to the trunk/branch. 
      There were 198 such changes between the trunk and the branches.
      Simple example:
      http://hg-pub.ecoscentric.com/ecos/rev/007ddf4d1979
      http://hg-pub.ecoscentric.com/ecos-v2_0-branch/rev/f30bba77e433

      PatchSet 593
      Date: 2003/02/24 14:04:35
      Author: jlarmour
      Branch: HEAD
      Tag: (none)
      Branches:
      Log:
              * sgml/doclist: Reorder in a slightly more logical order with
              related bits grouped together.
              Add docs for power management, USB (slave, eth slave, and
      SA11x0
              and NEC uPD8985xx drivers), and synthetic target HAL, eth and
              watchdog drivers.

              * sgml/.cvsignore: Add gifs and rename ecos.* to ecos-ref.*

      Members:
              doc/ChangeLog:1.13->1.14
              doc/sgml/.cvsignore:1.2->1.3
              doc/sgml/doclist:1.7->1.8
              doc/sgml/makemakefile:1.9->1.10



      /Notes:
      /
         1. /The CVS history file and CVS checkouts against a date
            confirmed that revisions checked in made after a branch also
            appeared in directly related branches./
         2. /changesets could not be transferred between branches
            because only *some* of the changes in a fair number of them
            propogated to other branches.  Hence individual commits were
            made to propagate only those changes that CVS reported./
         3. /When propagating changes, some changes appear within files
            within branches *before* their actual commit on another
            branch, while other changes magically appear on other
            branches sometime *after* the checkin. That is, CVS appears
            to invent time travelin both directions/./ This is fixed in
            the conversion by only propagating the revision to the other
            branches at the same time as the original commit./
            /
            /
   5. Create the creation of new branches as a clone from the ancestor. 
      Ignore the "Branches" tag from cvsps as it is too unreliable.  Not
      cvsps fault - CVS is just broken. Branches were manually cloned
      instead to closesr match the code. This was done to ensure that
      the actual changes of the first commit were preserved.
      /Note:
      /
         1. /The "Branches" and "Tag" labels within cvsps patchsets were
            only used as indicators when a branch or tag was made. 
            /
         2. /The CVS history file was used as the first reference to
            determine the time of the branch
            /
         3. /When the history file was not forthcoming (yes, it did not
            store every tag/branch, and occasionally even gave totally
            bogus information, looking like timezone bugs.) the time of
            the branch was calculated to be one second before the first
            commit to the branch./
         4. /Some files are only appear in a CVS checkout of a branch at
            their first change in the branch. These files existed when
            the branch was made, so should appear when the branch is
            checked out against a time prior to the change, but they did
            not./
         5. /Some files suddenly appear on a branch with the same
            revision as at the branchpoint //on their parent // at some
            arbitraty checkout time

            /
   6. hg tags are after the time of the last RCS commit of all the files
      that have the tag, just before the next commit.  In our simple
      example which tags a two sets of files at different times, the tag
      is made after the "newest" (greatest) time of all files containing
      the tag, one second before the next CVS commit.
      /
      /
   7. Some revisions of files or patchsets are orphaned.  They do not
      have a branch and do not belong on the trunk.  These summarised below.

   8. At periodic intervals, do a full CVS checkout of all active
      branches and compare these files against a hg "checkout" at the
      same time.  If all the comparisons of CVS against hg of the
      branches matched, create a checkpoint (a clone of the hg
      repositories).
      If there are any differences (ignoring files that do not appear in
      cvs but appear in hg), revert to a previous checkpoint and do a
      binary chop style search to find which CVS checkin resulted in the
      change and make the corresponding hg commit to bring the hg files
      in line with CVS. This was termed "Normalising" and the hg commit
      message reflected this process.  More than occasionally (like
      merges with anoncvs) such changes occurred at every small commit. 
      In these instances, with many CVS checkins occurring as part of
      the merge, a single "Normalisation" was done after the multiple
      CVS commits.

   9. At the end of the conversion process, do a full current checkout
      of both CVS and hg repos and compare.  All files matched.  However
      the flash_v2 branch which had additional files in hg due to
      normalisation.  These were removed in one final commit:
      http://hg-pub.ecoscentric.com/flash_v2/rev/3d4d52f8a035


Orphaned changes
================
PatchSet 582
Date: 2003/02/21 09:09:49
Author: bartv
Log:
Merge from trunk - tweak CDL testcase definitions to refer to the
executables rather than the source

Members:
        packages/io/fileio/current/ChangeLog:1.26->1.26.2.1
        packages/io/fileio/current/cdl/fileio.cdl:1.10->1.10.2.1
        packages/services/cpuload/current/ChangeLog:1.1->1.1.2.1
        packages/services/cpuload/current/cdl/cpuload.cdl:1.2->1.2.2.1
        packages/services/crc/current/ChangeLog:1.4->1.4.2.1
        packages/services/crc/current/cdl/crc.cdl:1.1->1.1.2.1


Odd usage notes
===============

Finally, I just imported the hg ecos repository into git, for the hell
of it, just to see, and it worked very smoothly.  However, I was
surprised to see that the repository was around 10% bigger than hg, upon
which I was informed about git-pack.  It seems busy git repositories do
need regular manual maintenance to stay efficient and small.  And as a
sub-note, when manually messing with changesets between hg and git, I
was disappointed to find that git requires the SHA-1 to refer to a
changeset while hg allows you to use both SHA-1 and a local id meaning I
ended up with a lot less cut n pastes with hg than I had to do with git.


Summary
=======
My preference is obvious: hg  Hence my continual lobbying :-) However,
more practically, my choice is mainly from usage and usability
experience. I would encourage you to use both hg and git on different
host platforms before making a decision so you can make your own mind
up. Regular git users should also try to be a bit more open minded and
remember that not every eCos developer uses linux and is a command-line
expert.  Neither eCosCentric nor myself have any commercial interest in
any of the DRCS options, nor do we stand to gain or lose commercially if
you choose one over the other. In particular I do not want hg to be
disadvantaged just because eCosCentric and myself have recommended it. I
am also sure the community would appreciate seeing a summary of how and
why you reached your decision if you decide to hold the decision process
behind closed doors.

Finally, if you have any questions, concerns or would like some help
setting up your own hg repository, including setting up push privileges
over https for maintainers (assuming you don't want to be exclusive
ssh), automated email sent when changes are pushed as well as automatic
updates of checked-out versions (e.g. web pages), I have done all of
these and will happily share my experiences or set it up for you on
sourceware.  It is pretty much a no brainer - all you need is a web
server (though not even that) with suitable local privileges.  OTOH all
of this is well documented and each option only involves a couple of
lines in your hgrc file, so you should be easily able to set it up yourself.

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: hg conversion notes and summary
  2009-10-12 12:34 hg conversion notes and summary Alex Schuilenburg
@ 2009-10-14 14:44 ` Alex Schuilenburg
  2009-10-16  4:21   ` Jonathan Larmour
  0 siblings, 1 reply; 7+ messages in thread
From: Alex Schuilenburg @ 2009-10-14 14:44 UTC (permalink / raw)
  To: ecos-maintainers

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.

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 :-)

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.

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 :-)

Cheers

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: hg conversion notes and summary
  2009-10-14 14:44 ` Alex Schuilenburg
@ 2009-10-16  4:21   ` Jonathan Larmour
  2009-10-16  9:44     ` Alex Schuilenburg
  0 siblings, 1 reply; 7+ messages in thread
From: Jonathan Larmour @ 2009-10-16  4:21 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: ecos-maintainers

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.

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

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

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

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).

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: hg conversion notes and summary
  2009-10-16  4:21   ` Jonathan Larmour
@ 2009-10-16  9:44     ` Alex Schuilenburg
  2009-10-16 14:10       ` Jonathan Larmour
  0 siblings, 1 reply; 7+ messages in thread
From: Alex Schuilenburg @ 2009-10-16  9:44 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-maintainers

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: hg conversion notes and summary
  2009-10-16  9:44     ` Alex Schuilenburg
@ 2009-10-16 14:10       ` Jonathan Larmour
  2009-10-16 23:37         ` Alex Schuilenburg
  0 siblings, 1 reply; 7+ messages in thread
From: Jonathan Larmour @ 2009-10-16 14:10 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: ecos-maintainers

Alex Schuilenburg wrote:
> Jonathan Larmour wrote on 2009-10-16 05:21:
> 
>>Alex Schuilenburg wrote:
>>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.

Given it's used by other projects, I'd have to give a good reason for 
potential disruption. If there is something concrete I could mention (bug 
X will make it hard, or it is missing important feature Y) that would be 
useful.

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

Shell accounts on sourceware are usually highly restricted, so yes.

> 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).

Would the bugzilla plugin need to live on sourceware or on the bugzilla 
machine?

You can defer answering till after a decision's been made :-)

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: hg conversion notes and summary
  2009-10-16 14:10       ` Jonathan Larmour
@ 2009-10-16 23:37         ` Alex Schuilenburg
  2009-10-27 15:09           ` Alex Schuilenburg
  0 siblings, 1 reply; 7+ messages in thread
From: Alex Schuilenburg @ 2009-10-16 23:37 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-maintainers

Jonathan Larmour wrote:
> Alex Schuilenburg wrote:
>> Jonathan Larmour wrote on 2009-10-16 05:21:
>>
>>> Alex Schuilenburg wrote:
>>> 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.
>
> Given it's used by other projects, I'd have to give a good reason for
> potential disruption. If there is something concrete I could mention
> (bug X will make it hard, or it is missing important feature Y) that
> would be useful.
Based on what you said below about shell access, I would not bother with
the upgrade now.  I was only thinking about those maintainers who did
not want to run hg on their local machine.  If sourceware were to only
be used to serve the repository (push/pull), I dont see a need to
upgrade.  I'll take a look through the changes anyway, just in case..

>
>> 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. 
>
> Shell accounts on sourceware are usually highly restricted, so yes.
OK, that could simplify things.

>
>
>> 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).
>
> Would the bugzilla plugin need to live on sourceware or on the
> bugzilla machine?
Not on the bugzilla machine, and given restricted shell access, not on
sourceware either.

First, let me clarify things. 

1) The bugzilla hg plugin is great for allowing you to track changesets
and bugfixes/contributions.  What it does is add a comment into a
bugzilla bug if that bug has been referenced in the changeset comment
(according to some predefined criteria). So, for example, if you are
committing a fix for a bug or a contribution submitted as a bug and have
something like "Fix for bugzilla 1000123", or "Integration of
contribution in bugzilla 1000123" within the changeset comment (CVS log
equivalent for newbies), it will add a comment to bug 1000123 according
to whatever template you specify.  For example:
  http://hg.mozilla.org/mozilla-central/ shows bug references,
and
  https://bugzilla.mozilla.org/show_bug.cgi?id=481775#c17
shows a minimal comment while
  http://developerbugs.linuxfoundation.org/show_bug.cgi?id=1443#c1
shows a more descriptive comment

Notes on implementation: The hg-bugzilla plugin does this using email,
sending email to the bugzilla email interface email_in.pl (which allows
you to add comments, etc).  The changeset will obviously not be visible
though until pushed into the main repository (unless of course the
commit is made on sourceware). 

Similarly you can set up your hg web interface to point to the bugs on
bugzilla (as per 1st url example), but that will most likely require
somebody to set this up on sourceware.

2) The hg email command (patchbomb extension) is a way changesets can be
packaged and sent in a standard form.  This can be to individuals for
review, mailing lists, a single file attachment to a bugzilla bug or
even the email_in.pl interface.  For an example on how one project is
does this, see http://libvirt.org/CIM/patches.html.  It gives a formal
specification to contributors on how to submit patches to the project
using the hg patchbomb extension.

If you choose bugzilla for submission of patches or contributions, you
would simply use the -m option of "hg email" to create a single mbox
file that would be added as an attachment to a bug report.  That would
be the contribution.  If accepted, a simple "hg import" of that file
will apply the contribution.

How simple is all that?

3) The direct submission from a contributor into bugzilla I mentioned
setting up is simply a morphing of (1) and (2).  It is not a standard
feeature and would need to be written (hence my offer), but is very
simple IMHO. It will probably be the most useful to regular
contributors, but equally could be set as the standard way to contribute.

It would simply require a modified email_in.pl interface (I have
contributed to this interface in the past, specifically addiing
attachments to bugzilla bugs, so I have a clue) to suck up hg patchbombs
and convert them into patch attachments within a single bugzilla bug
report. The 0'th email (the description) becomes the description, and
the [PATCH M of N] emails become the attachments.  Or it could collate
the all changesets into a single "hg email -m" style attachment.  Not
sure which is best, probably the latter for simplicity of application,
but equally the former makes it easier to comment on individual
changesets.  The morphing is simply the use of the bugzilla login info
needed for the bugzilla plugin to provide site and bugzilla security
(otherwise we end up opening bugzilla to spam).

For a description of the patchbomb extention, just run "hg help email"
on a system with it installed (it is distrubuted as standard and enabled
on our two main servers).



>
> You can defer answering till after a decision's been made :-)

I preferred now while it is all still fresh ;-)

BTW, I would like to point out a couple of high profile projects using hg:
Open Office:
  http://blogs.sun.com/GullFOSS/entry/openoffice_org_development_switches_to
FireFox:
  http://hg.mozilla.org/mozilla-central/
Google Code:
 
http://googlecode.blogspot.com/2009/04/mercurial-support-for-project-hosting.html
Python:
  http://mail.python.org/pipermail/python-dev/2009-March/087931.html
Linux-HA:
  http://hg.linux-ha.org/
NetBeans:
  http://wiki.netbeans.org/HgHowTos
OpenSolaris:
  http://opensolaris.org/
XEmacs:
  http://www.xemacs.org/
XEN:
  http://xenbits.xensource.com/

to name but a small few.  A bigger list can be found at:
  http://mercurial.selenic.com/wiki/ProjectsUsingMercurial

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: hg conversion notes and summary
  2009-10-16 23:37         ` Alex Schuilenburg
@ 2009-10-27 15:09           ` Alex Schuilenburg
  0 siblings, 0 replies; 7+ messages in thread
From: Alex Schuilenburg @ 2009-10-27 15:09 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-maintainers

Hi Jifl,

Just another couple of updates:

Alex Schuilenburg wrote on 2009-10-17 00:37:
> Jonathan Larmour wrote:
>   
> [...]
>>> 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).
>>>       
>> Would the bugzilla plugin need to live on sourceware or on the
>> bugzilla machine?
>>     
> Not on the bugzilla machine, and given restricted shell access, not on
> sourceware either.
>   
[...]

I have changed my mind on this and switched from using email to provide
bugzilla comments to using hg-bugzilla itself.  I found the email
interface has potential for pitfalls in user hg configury (smtp agent,
email address used/conversion/etc) when mixing with the patchbomb
extension, and anyway, what was I thinking - it is all distributed so
can be handled by anyone ;-)

eCosCentric will be maintaining an internal copy of the repository
anyway, so everything is configured on our hosts for bugzilla comments.
Nobody else needs to install anything, other than eCosCentric which
provides the bugzilla database anyway (and it is already installed).

The bugzilla comment will get added each time eCosCentric pulls in
changes from sourceware.  This is live now on eCosCentric repos and I
can make it live now on sourceware for you to test.  I just need to
uncomment a single line. That is, any CVS checkin or hg commit with "bug
#" in the commit message will result in a comment being added to the bug
in the bugzilla database.  The comment will appear to have been made by
the person making the commit, with links back to the repo, and the usual
bugzilla hooks (email etc) will follow.  The whole comment is fully
customisable so I have just used the one in the hg book, which was
better imho than the default.

The only additional configury was the mapping of checkin name to
bugzilla name, which I have done for all the known maintainers.

Apologies also for spamming, ecos-bugs@ecos.sourceware.org.  I was
testing email notification as well as bugzilla comments using pulls and
forgot to uncomment the placeholder email notification.

 
-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2009-10-27 15:09 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-12 12:34 hg conversion notes and summary Alex Schuilenburg
2009-10-14 14:44 ` Alex Schuilenburg
2009-10-16  4:21   ` Jonathan Larmour
2009-10-16  9:44     ` Alex Schuilenburg
2009-10-16 14:10       ` Jonathan Larmour
2009-10-16 23:37         ` Alex Schuilenburg
2009-10-27 15:09           ` Alex Schuilenburg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).