Issues with switching to mercurial
L. David Baron
close to the point where (as I understand the plan, anyway) the bulk
of developers move over to working on Mozilla 2 in mercurial. I've
been collecting a list of issues that I think need to be fixed
before that happens, along with other issues with mercurial that I
think ought to be fixed. Some of these issues are issues with
mercurial itself, some are clearly issues with our tools and
infrastructure, and some could potentially be blamed on either side.
I think it would probably be useful to share these concerns with
Mercurial developers; I'd be interested to know how much others
agree with them and particularly if there are existing solutions to
them that I'm not aware of.
The three biggest issues I'm worried about (and the ones that are
mixed between our side and mercurial itself rather than being purely
mercurial issues) are the following:
(1) [ Benjamin posted to the mercurial list about this one recently,
but my take on it might be a little different. ] We need a way to
know what changes were the tip of mozilla-central (i.e., trunk), and
as we throw more people at mercurial it needs to be more robust than
"please do things in the following way". Even with a DVCS, we need
to know which is the trunk because it's the most useful place to
concentrate regression-searching and other analysis of the history
of our code. This is because the trunk is expected to meet certain
quality requirements (compiling, passing tests, etc.) whereas
long-lived branches often do not meet these requirements (and, in
fact, that the changes have a large intermediate stage where they
don't meet these requirements is often the reason for using a
long-lived branch).
One way to do this is to require that branch history never be landed
in mozilla-central (which probably could be enforced through
mercurial's hooks rather than just relying on everybody to do the
right thing with a new tool). However, I'm very uncomfortable with
the idea of sacrificing the history of those long-lived branches (or
consigning those who want to search it to have to look up the
location of a separate repository that contains it) in order to get
this. I think in many cases we will want branch history revisions
to get merged in to the trunk. (I think this would have been useful
for things like the reflow branch.)
(2) We need to know who pushed changes to mozilla-central. We have
a culture of accountability around committing (or, in the future,
pushing) changes to the tree: committers/pushers are responsible for
not breaking the build, not breaking tests, not regressing
performance, etc. I'm *very* uncomfortable with trusting this to a
rule of "please identify yourself honestly" given how many
committers/pushers we have (and how new many of them are to
mercurial). Furthermore, I think it's actually useful to show the
changeset author as the person who really wrote the code, even if
they're not the person pushing it. However, we need to really know
who pushed it.
At the very least, this should be a publicly-viewable log showing
who pushed which changesets. Ideally, it would be annotations on
the changesets themselves. (I'm not sure if annotations is the
right term here. But I'm referring to a concept that I think a
bunch of other DVCS systems have, but hg currently doesn't: the
ability to add additional pieces of information to a changeset, such
as cryptographic signatures of code reviewers or testers, that are
not part of the atomic hash-identified changeset, but, once
attached, get pulled along with the changeset unless you make a
serious effort to separate them again. Annotations could also be
useful for solving problem (1). And having the time of the push
could help with problem (3).)
(3) We need to adjust our testing infrastructure to identify what
code is being tested. This may be less of a problem depending on
how we solve (1) and (2). However, based on the current situation,
we need significant changes to tinderbox (clients and server), our
testing infrastructure (to propagate the necessary information
through), the graph servers, and build identifiers so that we can
identify what is being tested. We currently do all this
identification based on the time of a pull from CVS. However, with
hg, the timestamp of a pull is (currently, at least) no longer
useful information, since a changeset can be created at one time and
pushed later (never mind that the time of changeset creation is
determined by the machine clock on the developer's machine rather
than the time on the server).
We've made a huge amount of progress with unit testing and
performance testing over the past few years, and I don't want us to
end up having to dig ourselves out of a hole and spend a lot of time
trying to get historical test runs to figure out when the
regressions happened (which I don't think ever really worked out for
the regressions in the early part of the 1.9 cycle... I think we got
the data, but it never really got looked at as it should have been).
(We also need to get all of this testing infrastructure actually
running on Mozilla 2; currently there's not a whole lot on the
Mozilla 2 tinderbox.)
There are also a bunch of issues I have with mercurial itself that
I'd like to see fixed, although I don't think any one of them in
alone should block our movement to it. The ones that bother me as
somebody who's been using mercurial for a while already are:
(4) I've found it pretty easy to get a corrupt repository. Hitting
control-C during or having a hook return an error during operations
involving pushing or popping mq patches or stripping revisions seems
pretty likely to lead to repository corruption. hg should be
changing files / data structures in the correct order, and
recovering from the resulting partly-inconsistent states if needed,
so that this simply doesn't happen.
(5) [this one is much more feature-ish; I'll just describe it here
very briefly] mq doesn't really do what I'd like it to do. In
particular, I'd like to be able to do more operations without
stomping on the files touched by my patches, such as merging a queue
against upstream revisions and updating to the new queue tip, and
even making edits that are part of patches lower on the queue (by hg
invoking my editor on a temporary file). I'd also like support for
reordering patches (with automatic merging), ability to diff the
queue repository before committing without cd-ing into .hg/patches/,
automatic (optional?) refreshing of the patch after a successful hg
qpush, and maybe even support for rolling back to a previous
revision in the queue repository (which would make the necessary
changes in the main repository). And I definitely want the hg
qrebase command proposed recently to make merging easier. I could
go into much more detail on a bunch of these, but that probably
belongs in another message.
(6) There are a bunch of difficulties getting diffs with more
context; I'm not sure if it's currently possible at all without
editing the mercurial source code (though it's a pretty easy edit to
change the default). Mozilla generally has a tradition of patches
with a significant amount of context (typically 8 or 12 lines),
which we find easier to read and review. It would be nice to be
able to do this both from the command line (for hg diff, hg export,
etc.) and as a global configuration option. Using it as a global
configuration option should affect the amount of context in patches
in .hg/patches/ for those using mq, which is good for those who like
to upload those patches directly (which I do, since it's much faster
than the alternative). However, as things work right now, this is
bad for actually using mq. Many operations in mq (for example,
editing a patch not at the top of the queue and then reapplying ones
above it, or many of the techniques for merging) actually apply
patches using patch. And patch determines how much context around
the edges of the patch to ignore based on its -F argument (F for
fuzz), which defaults to 2 on the assumption that diff defaults to 3
lines of context. (Really, patch is broken here, and it should have
an argument for how many lines of context are the minimum it can
leave, not how many it is allowed to trim off the edges.) Mq (and
other things in hg that call patch) should pass an appropriate -F
option to patch, preferably based on the amount of context actually
present in the diff, but, failing that, based on the global default
(at least for hg qpush; it might be a bad idea for hg import, hg
qimport, etc.).
The ones that caused me a good bit of confusion as a new user of
mercurial (the big ones that I still remember, anyway) were:
(7) Because the default diff format is not git-style diffs, the
default configuration can pretty easily lead to dataloss when mixed
with mq or when mixed with emailing patches back and forth. There's
no warning that the diff doesn't fully reflect the changeset (e.g.,
binary files get completely dropped from the diff and from the
changeset after a cycle of hg qpop+hg qpush+hg qrefresh). The
default diff format should be changed to either (a) always using
git-style diffs or (b) using git-style diffs when not doing so would
lose information.
(8) I've run into problems using "hg serve" because hg serve
responds to requests for any path. This is a particular problem for
hg qclone, which ends up cloning the main repository twice and not
getting the patch repository at all. (This was a few versions ago,
though (0.9.3, probably). I've since given up on bidirectional
sharing between machines and considered one of my machines the
master. I just checked that the path still isn't checked, although
I'm not sure if I'd still have the qclone problem.) It's also a
problem if I just run hg serve in the wrong directory.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Shawn Wilsher
files that doesn't involve me adding it to my patch queue. As far as
I know, there is no other way to do it.
When I'm doing reviews, I often like to apply the patch and make sure
it doesn't fail any unit tests. Patches that add unit tests and a
binary file (like, say, a sqlite database) are difficult at best to
apply.
Cheers,
Shawn Wilsher
Sergey Yanovich
> I think it would probably be useful to share these concerns with
> Mercurial developers; I'd be interested to know how much others
> agree with them and particularly if there are existing solutions to
> them that I'm not aware of.
The replied post raises a series of issues, which can be grouped into
two big categories:
* related to project management: (1) - (3);
* technical: (4) and after.
There is at least one project, that has acceptable solution to the whole
range of project management issues. It is kernel.org. I've tried to draw
parallels between the current Mozilla process and the kernel.org process
in m.d.platform thread "Mozilla 2 checkin patterns", but the best
solution may be to approach kernel.org people directly, and ask them to
share experience. Here is a link to a relatively recent post by Linus
Torvalds about DVCS:
http://marc.info/?l=git&m=117019819922641&w=2
The post answers some technical questions on git vs. hg, but also
contains clues on project management and DVCS use cases.
It may turn out, that the easiest way to solve hg technical problems is
to switch to git.
There were concerns about git performance on Windows, but msysgit from
http://code.google.com/p/msysgit/ feels at least as fast as hg 0.9.4 for me.
--
Sergey Yanovich
L. David Baron
> L. David Baron wrote:
> > I think it would probably be useful to share these concerns with
> > Mercurial developers; I'd be interested to know how much others
> > agree with them and particularly if there are existing solutions to
> > them that I'm not aware of.
>
> The replied post raises a series of issues, which can be grouped into
> two big categories:
> * related to project management: (1) - (3);
> * technical: (4) and after.
I said roughly that in the post -- but only roughly. (1)-(3) are
related to our tools and the way we use them (I'm not sure I'd call
that project management), but solutions for (1) and (2) and maybe
(3) (or good ones, at least) probably require features from
mercurial that it doesn't currently have.
Mark Banner
> As we're approaching release of Firefox 3, we're getting pretty
> close to the point where (as I understand the plan, anyway) the bulk
> of developers move over to working on Mozilla 2 in mercurial. I've
> been collecting a list of issues that I think need to be fixed
> before that happens, along with other issues with mercurial that I
> think ought to be fixed. Some of these issues are issues with
> mercurial itself, some are clearly issues with our tools and
> infrastructure, and some could potentially be blamed on either side.
My thought:
9) A clear, (preferably agreed) plan for other apps building and
developing alongside the main mercurical repository.
It doesn't have to be fully implemented/working (though it would be
nice), but it should be capable of working and with clear indications of
how this done, such that anyone can make it happen (either inside or
outside of MoCo).
It may be a while before some apps want to do this (because of their
release cycles), but please can we get something in place beforehand so
that apps have a chance of being able to build alongside the main
mercurial when their developers feel ready/able to do so.
Standard8
Benjamin Smedberg
> 9) A clear, (preferably agreed) plan for other apps building and
> developing alongside the main mercurical repository.
Please see my post to Kairo in the "Thoughts on 1.9..." thread. Other than
nobody has done specifically with mozilla-central yet, this is the same
problem that songbird and other XULRunner-based apps have dealt with and
solved during the 1.8 and 1.9 cycles.
--BDS
Benjamin Smedberg
> (1) [ Benjamin posted to the mercurial list about this one recently,
> but my take on it might be a little different. ] We need a way to
> know what changes were the tip of mozilla-central (i.e., trunk), and
> as we throw more people at mercurial it needs to be more robust than
> "please do things in the following way". Even with a DVCS, we need
[snip]
> (2) We need to know who pushed changes to mozilla-central. We have
> a culture of accountability around committing (or, in the future,
[snip]
I have written a mercurial hook to collect the revision/date/pusher for
every commit to a repository (mozilla-central), as a security/blame
mechanism if nothing else:
http://hg.mozilla.org/users/bsmedberg_mozilla.com/hghooks/
Publishing this file on the web is also pretty simple; integrating it with
our tools so that you can navigate the history as it was in mozilla-central
is more complicated. I have written up a description of mercurial
improvements that mozilla is going to contract for. Section 3 is almost
entirely dedicated to this issue:
http://developer.mozilla.org/en/docs/Mercurial/Desired_Features
> (3) We need to adjust our testing infrastructure to identify what
> code is being tested. This may be less of a problem depending on
> how we solve (1) and (2). However, based on the current situation,
> we need significant changes to tinderbox (clients and server), our
> testing infrastructure (to propagate the necessary information
> through), the graph servers, and build identifiers so that we can
> identify what is being tested. We currently do all this
> identification based on the time of a pull from CVS. However, with
> hg, the timestamp of a pull is (currently, at least) no longer
> useful information, since a changeset can be created at one time and
> pushed later (never mind that the time of changeset creation is
> determined by the machine clock on the developer's machine rather
> than the time on the server).
>
> (We also need to get all of this testing infrastructure actually
> running on Mozilla 2; currently there's not a whole lot on the
> Mozilla 2 tinderbox.)
Yes... alice and I have discussed this, though haven't come to any good
conclusions yet. My fairly strong preference is that the talos boxes should
report test results graphed against changeset ID instead of date for
mozilla2, but this is a pretty significant change to the testing
infrastructure and it's not clear whether it's practical at this point. The
alternate solution of contuing to report numbers by date and correlate those
against the mozilla-central log created above is much simpler.
There are currently talos boxes for testing the mozilla-central and
actionmonkey builds, and they have been reporting to MozillaTest... I think
at least the mozilla-central ones are almost ready to turn live and report
to the Mozilla2 tinderbox.
I've also brought up the need for build, performance, and unit-test boxes
for feature branches, and we're planning to have capacity to do full testing
for these branches, though perhaps less often than mozilla-central: e.g.
build/unit-test/perftest actionmonkey twice a day or on checkin.
> (4) I've found it pretty easy to get a corrupt repository. Hitting
> control-C during or having a hook return an error during operations
> involving pushing or popping mq patches or stripping revisions seems
> pretty likely to lead to repository corruption. hg should be
> changing files / data structures in the correct order, and
> recovering from the resulting partly-inconsistent states if needed,
> so that this simply doesn't happen.
I've had this happen a couple times, mainly when dealing with mq and qsave.
The one repeatable testcase I have has been fixed in mercurial-crew (and I
think crew-stable) and should be in hg 1.0. It is a case where you do a
qpush -m and then try to qpop the old queue without popping the new queue:
in that case it will strip revisions in an incorrect order.
If you find other cases where this happens, please file bugs in
http://www.selenic.com/mercurial/bts/ and mail me about them: we can
dedicate contracting resources to fix them.
> (5) [this one is much more feature-ish; I'll just describe it here
Agree that this entire set of features is desirable: not going to block on
any of them, but if you can find time to write up in contractable detail how
any of them would work, I may be able to find some resources for the ones
that are most important.
> (6) There are a bunch of difficulties getting diffs with more
> context; I'm not sure if it's currently possible at all without
> editing the mercurial source code (though it's a pretty easy edit to
> change the default). Mozilla generally has a tradition of patches
> with a significant amount of context (typically 8 or 12 lines),
> which we find easier to read and review. It would be nice to be
> able to do this both from the command line (for hg diff, hg export,
Well... extdiff *can* mostly do what you want, but setting it up and getting
the syntax right is a royal pain. I agree completely that this is a pretty
serious problem.
Can you write up a proposal that's suitable for contract and I'll add it to
our list?
> (7) Because the default diff format is not git-style diffs, the
This is just a bug in hg, in my opinion. [diff] git = 1 should be the
default. Has this been discussed on the mercurial list?
> (8) I've run into problems using "hg serve" because hg serve
This is minor, IMO, but it's also probably pretty trivial to fix.
The relatively simple workaround is to use a server (such as a user-clone on
hg.mozilla.org) to share a repo across machines.
--BDS
Justin Wood (Callek)
Not having (ever) known what the Songbird solution was/is. Any
links/answers to this, or how the cvs-model to this answer applies to
Mercurial.
After reading that and this reply, I still don't see it.
--
~Justin Wood (Callek)
Sergey Yanovich
> If you find other cases where this happens, please file bugs in
> http://www.selenic.com/mercurial/bts/ and mail me about them: we can
> dedicate contracting resources to fix them.
Is there a final decision to choose Mercurial as the Mozilla 2 VCS?
The last word was that the issue should be re-evaluated somewhere around
now (January - March 2008):
http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html
--
Sergey Yanovich
Benjamin Smedberg
> Is there a final decision to choose Mercurial as the Mozilla 2 VCS?
>
> The last word was that the issue should be re-evaluated somewhere around
> now (January - March 2008):
>
> http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html
The only viable contenders at this point are Mercurial and git. Git might be
better in technical theory, but is clearly harder to learn for beginners. So
we'll be sticking with Mercurial for the time being.
--BDS
Benjamin Smedberg
> Not having (ever) known what the Songbird solution was/is. Any
> links/answers to this, or how the cvs-model to this answer applies to
> Mercurial.
>
> After reading that and this reply, I still don't see it.
Use a driver script (like client.mk in CVS) to check out XULRunner sources
(and apply patches if necessary) and check out application sources. Then
build using --enable-application=foo.
--BDS
Jean-Marc Desperrier
Git did seem rather easy from the description here :
http://www.bluishcoder.co.nz/2007/06/using-git-to-track-firefox-cvs.html
http://www.bluishcoder.co.nz/2007/06/viewing-firefox-cvs-changes-via-gitweb.html
fantasai
I don't know anything about either system, but if there's a document like
http://developer.mozilla.org/tools/cvs/
for whatever we're using I think beginners will do fine. (I put that together
from existing documentation and reviewers' comments when I was still getting
used to command lines and CVS. Used it myself a lot: it's what I wished we
had when I was learning.) If there isn't a document like that for the VCS
we're using then I suspect beginners will be frustrated either way. (I'll be
frustrated, at least.)
I'd be more worried about the people doing RCS archeology, juggling multiple
patches, and twisting branches around having a hard time learning the new UI.
But they would also be the ones more affected by the technical limitations.
~fantasai
who's still somewhere between beginner and intermediate CVS user
Håkan Waara
> Benjamin Smedberg wrote:
> > Sergey Yanovich wrote:
>
> >> Is there a final decision to choose Mercurial as the Mozilla 2 VCS?
>
> >> The last word was that the issue should be re-evaluated somewhere
> >> around now (January - March 2008):
>
>
> > The only viable contenders at this point are Mercurial and git. Git
> > might be better in technical theory, but is clearly harder to learn for
> > beginners. So we'll be sticking with Mercurial for the time being.
>
> I don't know anything about either system, but if there's a document like
> http://developer.mozilla.org/tools/cvs/
> for whatever we're using I think beginners will do fine.
http://developer.mozilla.org/en/docs/Mercurial is a start. That
together with http://wiki.mozilla.org/Using_Mercurial_locally_with_CVS
was enough to get me started this weekend, not having touched hg
before.
/Håkan
Sergey Yanovich
> The only viable contenders at this point are Mercurial and git. Git
> might be better in technical theory, but is clearly harder to learn for
> beginners. So we'll be sticking with Mercurial for the time being.
I would like to read "time being" as "no final decision, yet", so I'll
argue a bit more. Feel free to stop me, if the assumption is wrong :)
Git is not a technical theory. It is a tool, specifically developed to
manage a very dynamic distributed open-source software project, which is
what linux kernel is.
It is true, that git may be slightly more difficult to learn for
beginners than Mercurial. But there are good reasons for that. Git is
designed by a person overwhelmed by integration routine, and it is
designed to relieve that person from that routine, and git is succeeding
with that task.
Mercurial is a great tool compared to CVS or SVN, or just about anything
else in VCS world. But it lacks one important feature, that Mozilla
needs -- solid branching support. The recommended way to branch in
Mercurial is to create a hardlink copy of the tree. Needless to say,
this doesn't work on w32.
Correct me if I wrong, but Mozilla 2 team VCS usage pattern doesn't
include lots of branch merging. Instead, it concentrates on patch
queues. That is not the most efficient approach, because applying a
patch queue (even with git rebase) requires considerably more conflict
resolving, than doing a merge between git branches.
If a line present in several patches changes in trunk, it will produce a
conflict for every patch with this line, if you apply the queue, but
only one conflict, if you merge with git. Git merge also allows to
resolve each conflict only once. To achieve this with patch queues, you
need to be constantly editing your queue as trunk evolves. Mercurial can
probably do smart merging also, but that only part of the deal. To be
able to merge, you both branches in your local repository. And handling
a repository with 20+ topic branches with criss-cross merges is just
where git excels.
20% of people usually do 80% of work. So it is a bad idea to reject a
tool that increases productivity of those 20%, because it also forces
the rest to learn a new tool.
--
Sergey Yanovich
Rob Arnold
> Mercurial is a great tool compared to CVS or SVN, or just about anything
> else in VCS world. But it lacks one important feature, that Mozilla
> needs -- solid branching support. The recommended way to branch in
> Mercurial is to create a hardlink copy of the tree. Needless to say,
> this doesn't work on w32.
The Win32 API has supported hardlinks on NTFS since Windows 2000. Is the
issue that Mercurial is not using them or that creating a hardlink copy of
the tree is a bad way to branch? How does git approach this problem and why?
I am not trying to be accusitory here, merely curious. I have yet to really
try git since it does not yet run on win32 natively (Cygwin does not count
as native and msys has quirks) and that has kept me from working on cairo.
-Rob
Sergey Yanovich
> On Tue, Mar 11, 2008 at 7:16 AM, Sergey Yanovich <ynv...@gmail.com> wrote:
>
>> Mercurial is a great tool compared to CVS or SVN, or just about anything
>> else in VCS world. But it lacks one important feature, that Mozilla
>> needs -- solid branching support. The recommended way to branch in
>> Mercurial is to create a hardlink copy of the tree. Needless to say,
>> this doesn't work on w32.
>
>
> The Win32 API has supported hardlinks on NTFS since Windows 2000.
Didn't know that. Always thought that both 'ln' and 'ln -s' commands in
msys shell are plain copy equivalents. I'll try this. Immediate
question: does Mercurial breaks NTFS hardlinks?
> Is the
> issue that Mercurial is not using them or that creating a hardlink copy of
> the tree is a bad way to branch?
The latter. It actually means one branch per repository recommendation.
Patches or equivalent transport media required to transfer changesets
between repositories.
> How does git approach this problem and why?
In short, git uses object storage model, while Mercurial employs delta one.
Git can handle arbitrary number of branches inside single repository
without any adversary effects on performance or stability. Branches may
or may not have common revisions and/or objects. You can work on all
those branches using single source tree (VPATH builds help a lot here).
New branch is just a 40 bytes text file, so branch creation is instant.
After merging branches with 20MB diff between them, repository footprint
will grow by less than 1kB (if there are no conflicts). A repository
with 20 branches with 100 MB history each and criss-cross merges will
occupy 100 MB of disk space.
> I am not trying to be accusitory here, merely curious. I have yet to really
> try git since it does not yet run on win32 natively (Cygwin does not count
> as native and msys has quirks) and that has kept me from working on cairo.
Git runs on w32 natively just fine with msysgit
(http://code.google.com/p/msysgit/ ). Performance just rocks. Merges
between mozilla branches take like 5 sec.
http://repo.or.cz/w/mozilla-1.9.git provides web interface to trunk and
contains instructions for checkout.
--
Sergey Yanovich
Benjamin Smedberg
> I would like to read "time being" as "no final decision, yet", so I'll
> argue a bit more. Feel free to stop me, if the assumption is wrong :)
We're going to keep using Mercurial for the next 12 months at least. We may
choose to revisit that decision later, but arguing about it now is not going
to help.
> Mercurial is a great tool compared to CVS or SVN, or just about anything
> else in VCS world. But it lacks one important feature, that Mozilla
> needs -- solid branching support. The recommended way to branch in
> Mercurial is to create a hardlink copy of the tree. Needless to say,
> this doesn't work on w32.
This is not true on both counts. If you have an NTFS file system Mercurial
will use hardlinks for local clones. And, you can branch locally either with
multiple heads or using named branches.
> If a line present in several patches changes in trunk, it will produce a
> conflict for every patch with this line, if you apply the queue, but
> only one conflict, if you merge with git. Git merge also allows to
> resolve each conflict only once. To achieve this with patch queues, you
> need to be constantly editing your queue as trunk evolves. Mercurial can
> probably do smart merging also, but that only part of the deal. To be
> able to merge, you both branches in your local repository. And handling
> a repository with 20+ topic branches with criss-cross merges is just
> where git excels.
It is important to Mozilla to have a history that is relatively clean, as
well as follow the existing model of review-before-"commit", where "commit"
means push to mozilla-central.
The advantage of patch queues are that you can work on a series of changes,
related or not, without maintaining multiple object trees... you can then go
back to earlier patches and fix review issues. More total merges are
required, but in my experience these merges are no worse, and sometimes much
easier, than simply merging the end of a branch.
--BDS
Sergey Yanovich
> We're going to keep using Mercurial for the next 12 months at least. We
> may choose to revisit that decision later, but arguing about it now is
> not going to help.
Fair enough. Point taken.
> It is important to Mozilla to have a history that is relatively clean,
> as well as follow the existing model of review-before-"commit", where
> "commit" means push to mozilla-central.
Irrespective of employed VCS, I have some general ideas here. My field
is accounting. There is a trend called 'through-put accounting'. It has
Drum-Buffer-Rope concept. In short, the concept says:
* Drum. Each system has a bottleneck. System's through-put equals
bottleneck's through-put. To maximize system performance make the
bottleneck a drum, that always booms.
* Buffer. To prevent the drum from stopping to boom, keep a buffer just
before it.
* Rope. To prevent waste of resources, only the drum is allowed to
*push*. Rope is used to *pull* required resources through from the
bottom of the system up to the buffer, when the buffer is below a
certain level.
Numerous successful systems starting from a dvd-recording program to
Toyota automobile plants employ this system. Linux kernel is also
managed in the similar way. Applied to Mozilla 2 the concept is:
* Drum -- mozilla-central. Firefox drivers granting a+ function as drum
managers ATM.
* Buffer -- not sure. Module trees, managed by module owners is a good
candidate.
* Rope -- not sure. Module owners pulling individual bug patches from
bugzilla, or creating landslide patch queues for API breaking changes,
*and* pulling from mozilla-central may work.
There is no place for conflicts at mozilla-central, so Firefox drivers
pulling from module trees to mozilla-central seems the best solution.
There is also no place for regressions in mozilla-central, so merge
points need to be tested before pulling.
--
Sergey Yanovich