Decius wrote:
] You blog, but don't oped.... Sure, call me out. That does work after all. What can I say, I'm usually busy doing stuff, I always intend to revise later, I never do. I'm sitting on the floor, laptop propped up on a cardboard box. Phbttt. ] Monotone vs. Subversion vs. CVS??? There is a clearly perceived problem among the Digirati. Managing source code with multiple people working on it is a royal fucking pain in the ass. There are many people working on this problem for that reason.. It really picked up when there was a big stir about the Linux Kernel not being developed with an open tool chain when Linus switched his repository to BitKeeper. Everyone knows its time for CVS to die, but there are many ideas of which direction to go. The key engineering design point in play here is the good old centralized authority vs. decentralized structure.. And well, I don't necessarily know what to make of this Monotone yet. All I did was read the FAQ. Let just say its interesting: ] Monotone does not have a specific networking protocol. Each
] type of change or certificate has a serialization format called
] a packet, which is a pleasantly-formatted stream of ASCII
] text. The state of a monotone database is captured by a set
] of packets. Packets can be sent to mail or news servers, or
] posted to web CGI programs, and retrieved by other users.
] Packets can also be emailed, printed out, backed up,
] or whatever. ] An important fact about packets is that they are informative,
] and do not represent a conversation or any commitments by
] the sender or receiver. A packet is simply a representation
] of some fact. For most functions, monotone decides what to
] do by interpreting the facts it has on hand, rather than
] having specific conversations with other programs. Only the
] fetch and post commands exchange data -- in the form of
] packets -- with anyone else on the network. The rest of the
] time, monotone is "offline". ] Monotone ships with simple client implementations of the
] NNTP, SMTP and HTTP protocols, so that you can exchange
] packets with existing servers 'out of the box'. If you want
] to transmit packets through some other means, monotone
] can produce and consume them on the command line, as
] ordinary data. So basically, it determines if there are changes by comparing SHA1 hashes.. Files don't have version numbers, they have hashes. Changes go out in packets, and any given repository gets to decide what it wants to do. I have not really done all my homework here, but there are a few things about this I find intriguing. If I read this right, everything this RC system does, it can do blind. Or at least doesn't require any kind of state to be kept between clients. If it was necessary to distribute changes to an app in a way where it was not possible to maintain any kind of centralized resource - even a place to send changes to - this would be very useful. It would be possible to "broadcast" changes in situations where proper level of anonminity could be maintained, and as long as the proper people were looking they could merge any changes. Newsgroups, message boards, stego sequences in frames of Bin Laden video, whatever. So anyway, there is some op-ed.. I'm going to Home Depot to buy a door and two cheap sawstands to use as a desk. RE: monotone: distributed version control | 
