Wow! I almost missed this as I got dragged on to other things.
Great Post! Thanks for the effort I really appreciate it.
On Thu, 1 Mar 2007, Matthew Gregan wrote:
If there aren't many people on the list interested, it's probably better to
take it off list or move it to the monotone-devel list, IRC, or
something... it's only Linux related in that it happens to run on Linux, and
Linus once considered it while looking for a replacement for BitKeeper
before he went of and wrote Git (parts of which were quite strongly
influenced by monotone). :-)
Contrariwise. VCS systems are far wider than just Source control. Home
directories, documents, config files, web server layouts are all good
things for them to crunch on.
Our merging algorithm is provably correct. There was a large amount of
discussion on how to do merging correctly about a year ago. Our merge
algorithm is a result of that discussion (and a lot of hard work by some of
our developers). So far, we're the only VCS to adopt this algorithm.
Every now and again somebody here hits something weird in the CVS diff3.
(There's an interesting project on the TODO list to integrate monotone's
network code with something like XMPP to provide presence notifications of
other monotone users participating in a Jabber network. This, combined with
some NAT traversal to deal with today's Internet, would let you say 'hey,
Steve's just come online, sync my repository with his' and all the fiddly
stuff like sharing IP addresses and port numbers could be hidden and
automated.)
Hmm a couple of interesting questions on that...
The rest of monotone's commands never touch the network, and they don't need
to because you've got all of the history locally. Naturally, this means
that history inspection commands such as 'log' and 'annotate' work locally
and run fast.
1) Our CVS repository for one of our projects is 1gb in size, although
the app is about 55Mb in size. ie. Lots and lots of history and tags
and...
Usually every developer has several checkouts on their box at one
time as the work and collaborate on different things. ie. 55mb * 10
maybe.
So does this mean each developer would need 1gb of disk space for
the repository + 55Mb per checkout (not too bad). Or does this mean
that each check out of a version onto a local drive includes all
versions ie. 1Gb per checkout (which would be awkward)?
2) By "sync" repositories do you mean
* "this particular branch tip" is the same as "that particular revision"
or do you mean
* "all revisions ever, no matter how embarrassing, that ever were in
my repository are now in yours and yours in mine"
or what precisely?
As far as releases go, we're not at that magic 1.0 version number yet (0.33
was released today), but we are getting pretty close. The only thing
holding off 1.0 is waiting for additional functionality and some UI polish
that we consider a must.
Looks good enough to take it up for my own toys, but the 0.33 is a bit
scary. I can't see any chance of convincing the PHB's to move to
anything with a < 1.5 version number.
encountered conflicts, pull first
Argh!
monotone won't do this to you:
>snip<
As a result of this, if you're a new user and scared of dealing with
merging, you can ignore that and leave it up to a more experienced member of
the team. Just commit your work and sync. Someone experienced can merge
the branch later. We're the only system that offers that.
Sounds Good. Very Good. One of my prime moans at the moment is CVS is
confusing the issue of "sharing the code with the team" with "I
declare my code fit for public consumption" and "I need a version control
system to track my changes".
Some statistics on the code:
- ~20,000 lines of executable code
- ~1,280 assertions (1 in ~15 lines)
- ~550 log statements (1 in ~35 lines)
- ~370 data instrumentation statements (1 in ~53 lines)
- total of 1 in ~9 lines devoted to error detection/diagnosis
- 425 integration tests
- ~100 unit tests (each one tests a number of things)
- ~95% test coverage
Good! Very Good!
Coding style:
- don't use pointers
- don't use heap allocation
the sort of rules I would expect in an embedded system, curious to
find it here...
Hmm. Let me look at this HACKING file, browse source. AARGH! Scary!
http://viewmtn.angrygoats.net/
which is the One True Source?
Hmm. I think I have found it...
http://viewmtn.angrygoats.net/revision/browse/f93b47fe55221c5ce51cc01e522ec0b92df49a2b
Hmm. Ok, do you mean just use automatic stack variable and auto_ptrs?
Logging is always enabled (directed to a circular buffer in memory, we dump
it out on crash or log it was we go if run with --debug). Crash logs
include dumps of all of the interesting data structures that were in scope
at the time of the crash. GDB is fairly useless for C++ and particularly
the STL, but thanks to the above we hardly ever need to use it.
Not entirely, you do need to write little gdb commands to unwrap the
stl constructs but you can.
Still I love the circular buffer logging & dump on crash. Excellent!
We have continuous building and testing running for a number of platforms on
each commit to mainline using BuildBot.
Excellent!
You guys are certainly world class in doing several "Best Development
Practices", I'm impressed.
I definitely will be following Monotone closely (especially since I
getting whinges from some of the guys about svn)
You say you did this as a Summer of Code thing? Are you still a
student? What year doing what?
Thanks!
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [EMAIL PROTECTED]
New Zealand
