[Monotone-devel] Re: GCC and Monotone

[graydon hoare]

Zack Weinberg wrote:

> I can guarantee most GCC contributors
> don't want to install apache or other web server just to continue
> working.

right, so there's 2 other main options: send your posts to a mailing 
list, or send them to a news server. monotone can send packets to both 
(though it will need some procmail glue to *get* packets from the 
mailing list). we might well expand the set of URL schemes in the future.

> Again I'm sure this can be done with monotone I just don't know how;
> in particular I don't know how one changes the "official top of trunk"
> on the "official" depot.  Propagate commands?  Magic emails?

officialness isn't something you get to decide, absolutely, for the 
clients. you can of course publish "official" approval certs, signed by 
a key you advertize on www.gnu.org, but clients might decide to avoid 
such versions until they have certs from 3rd party testers and 
reviewers, too. monotone's designed to decentralize authority.

try not to think of HTTP "depots" as VC servers. they are just 
communication servers, just like a news server. they confer no authority 
at all.

> Here's where I'd really like more detail on how it works.  I don't see
> the answers in the manual.  Someone sends in a patch via email - I
> assume this is via "monotone post".  I want to approve it into the
> official tree. What exactly do I do?

you issue a cert which looks like this:

  [mcert 6232f6768f9d6726876fed3af6c4662653c74298
   approve
   address@hidden
   dHJ1ZQ==]
sDFRkHwflgBO2tgxdqS+x8TqcRVIPX6IYMXSh77qnGvrPPQbEkFa2nGGgNLrpXtQwGdajvkD
arF7DGhM0M0ASF7i/AYvn2ESuI59yqQQ/+PK8KW7i+0yWY4HW0dlyXEoo28fh3NDFHXt5dk1
JkTC7CElaOyhCKGErQu2y6sNqxw=
  [end]

it's issued by running a command like so:

 $ monotone approve manifest 6232f6

then anyone who sees this cert and trusts your approval may (or may not, 
you don't get to decide for them) update their tree to state 6232f6. 
probably they'd wait until they saw results from an auto-tester, too.

note: the infrastructure for this all working is not complete; we have 
enough problems right now getting the "trust me iff I commit" mode of 
operation working smoothly. but this is the direction we're going.

> Something you don't address is disk usage.  Do I have to have a
> complete copy of the GCC revision history on my local disk, even if I
> don't want to?  How big is a complete copy anyway?  (Assume ~100MB
> is acceptable for a large number of people, ~1GB is not.)

GCC's entire history in a monotone database is about 800mb (vs. 1.1gb in 
CVS archives). but that includes (a) everything back to the '80s, and 
(b) all the branches. few normal developers want all that history, and 
there's no obligation for them to have it.

the only times you need history are:

  - you want to visit it
  - you want to produce a diff against it
  - you want to use a historical state as a 3-way merge ancestor

it works fine from a limited subset of history. we'll probably have to 
write some special commands for cooking up precise (branch, time-window) 
subsets of history. such subsets might also naturally arise by people 
(socially) associating branches with depots, and only fetching from the 
depots they're interested in.

> Why not rename gcc-3_3-branch to org.gnu.gcc.3_3 ?

oh, just because the CVS importer builds branch names by looking at the 
existing CVS branch tags. I guess we could write a hook to let you strip 
out redundancy in existing branch tags, too.

-graydon