Re: [Monotone-devel] newbie question - SHA1 vs serials

[K. Richard Pixley]

Nathaniel Smith wrote:

For greater assurance, it is also easy to run multiple netsync
servers, all synchronized with each other at regular intervals by an
automated process.  Not only are these servers all backups of each
other (with a backup interval measured in minutes, rather than
"nightly" or the like), but they are _hot_ backups -- if a server goes
down, everyone can simply switch to another with no downtime.  They
can also be used for load balancing; it doesn't matter which server I
talk to, since any changes I push to it will end up in the other
servers as well within minutes.
  

These points are all significant and very strong selling points for monotone, in my opinion.  They also seem to be fairly unique to monotone at this point in time.

Years ago, (~1992), when I was working on CVS and became sufficiently disenchanted to consider writing an alternative, the "multiple head" facility is the bit I never twigged to.  This allows repositories to sync in the background and "collisions" to happen without blocking the syncs.  It also allows the developer who creates the fork to be the one to merge it, unlike, say, gnu arch or clearcase multisite which virtually require some other developer to do the merge.

Also superior to clearcase multisite, branches are not required to be owned.  FTR, in clearcase multisite, your site has a branch, my site has a branch, our branches are read-only to the other.  We work, our transactions propogate in the background, but if I want your work, I must merge it from your branch, which is read-only to me, into my branch.

Alternately, it's possible to play games with ownership and pass the ownership token back and forth, though this tends to be fraught with peril, confusion, and highly error prone as, just like luggage on an airline, it frequently gets misplaced for periods of time.

The ability to force branches to be read-only or only written by certain people is a benefit.  But requiring this restriction, as is done in multisite, isn't wonderful.  IMO, monotone is superior here, though it would be clearly superior if it were possible to restrict a branch - not just decline to merge, but actively decline to accept certain revisions.

--rich