Mozilla project choses Mercurial

[Daniel Holth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

solo turn wrote:
> except http://dbaron.org/log/2007-04#e20070417a  (which basically says
> common operations require way too many steps).
I thought that was an interesting post. He says:

"(The basic idea is to maintain a branch for each change and an
integration branch that integrates all of them.)"

Perhaps he wants:

a -> b -> c
b -> d
b -> e
...
b -> z

The project has a long and illustrious history ending at b. I want to
make a bunch of more or less unrelated changes, and I want to test
them in some sort of integration branch, and then I will eventually
promote some of them, and it's not just me developing these changes.
Other developers are working on changes c-z in their own workspaces.
We want to test them in the same place because it is more efficient
and because integration testing is important.

So I merge changes c-z together to build my integration branch. Let's
say they all touch different files so we don't need to use a merge
program. Changes e-m pass testing. Now I make a new branch that just
has e-m merged together on top of b, test it again, and release it.

So I would be creating a lot of merges that I can never push and merge
back into the regular development of the project, that were merely for
integration testing.

I have a vague idea of the scripts one might need to accomplish this.



Q. How do I keep track of branches c-z? In my experience, after there
are more than three or four heads in a Mercurial repository, things
get really confusing. I don't have the option of creating 26
repositories when the Mercurial assumption of "a complete copy of
everything is super cheap" is false (800 MB per copy, and the IDE or
web server doesn't know how to point to that many different directories).

Q. When everyone is working on the same project that must be "always
ready to release", but most developers are not merge-meisters by any
means, how do we keep it stable without over-burdening the merge meisters?

Q. What kind of system would I need to be able to rebase a-la git
(e.g. hg qpop -a ; hg update ; hg qpush -a) AND work on the set of
rebased revisions with another developer who has done their own rebase
to a slightly different base revision? Could each revision or
rebased-stack somehow have its own change and merge history?

Q. Can Mercurial do a better job of preserving the history of which
revision was tip over time?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGS8beVh4W2pVfoMsRAkC3AJ9HVI6gse6SEPAbcgaMGMFXVuVWwQCghc84
ANJkbsKk8mWvNQP87b2NjVU=
=SYYw
-----END PGP SIGNATURE-----