Slashdot Mirror
Tom Lord's Decentralized Revision Control System
Bruce Perens writes: "He'll have to change its name, but Tom Lord's arch revision control system is revolutionary. Where CVS is a cathedral, 'arch' is a bazaar, with the ability for branches to live on separate servers from the main trunk of the project's development. Thus, you can create a branch without the authority, or even the cooperation, of the managers of the main tree. A global name-space makes all revision archives worldwide appear as if they are the same repository. Using this system, most of what we do using 'patch' today would go away -- we'd just choose, or merge, branches. Much of the synchronization problem we have with patches is handled by tools that eliminate and/or manage conflicts -- they solve some of the thorny graph topology issues around patch management. Arch also poses its own answer to the 'Linus Doesn't Scale' problem. This is well worth checking out." If you're asking "What about subversion?", well, so is Tom.
A more distributed source control system could obviously circumvent problems like these, but with this caveat: the code that different groups work on would need to be sufficiently black boxed that most changes wouldn't require changes in other projects. It's just good programming style, but I know that this wasn't the case at ACME, and given my experiences with Corporate America I doubt it's true in most places. Maybe I'm just being pessimistic...
Anyway, it sounds like a good idea if it's used right.
The ability to do distributed development, manage multiple (possibly hostile or private) branches at once, good merge and diff tools, etc. sounds sort of like ClearCASE. Except of course that ClearCASE costs money, and doesn't have the global namespace thing going on. Rational had better be careful or their customers are going to move over to arch (especially since their Unix GUIs have sucked more and more with each successive release).
Bravo to the author on this tool - it sounds like a great advance of the state of the art if it works like he says.
Your right to not believe: Americans United for Separation of Church and
I don't see this as a big deal (or a big problem) at all. If you simply prefaced the name of each module with the fully qualified domain name of the server it happens to be sitting on, you'd accomplish this painlessly. This is already recommended practice for third-party Java developers (a package called 'widget' developed at acme.com would be called com.acme.widget)
Whether Alan Cox (or whomever) uses patches or some other source control (like arch) (a) you still have to download the software from a remote site (i.e., the Net) and (b) Alan still has control over what makes it into his repository.
The point is that it allows separate developers (AC, AA, LT, etc. in the kernal case) all to maintain their OWN trees while enjoying the powers of source control software. The added benefit of arch is that their separate trees are all connected without having to give write-permission to each other.
ClearCASE has been doing this for many years now.
Nothing new. not revolutionary...
i know. I'm just an AC, but i am right.
ACID (Automicity, Consitancy, Isolation and Durability) is only something that has been implemented and tested well on high read RDBMS such as Oracle.
When you think about that, why is it that no one is using a DB backend to source control? Wouldn't that just get rid of so many ambguities? For one, we wouldn't have to deal with all the nonsence and create a million wheels, when a nice pair of rolls royces resides with a good RDBMS.
People need to think outside their brains, and in regard to source control, I feel we need to make more packages that interface well with a good RDBMS rather than create our own RD functionality in 40ks. What's the use?
Anyone know a good system of incoroprating source control with a databases? Oracle and Postgres would do.
This is incorrect. The CVS numbers are internal. If you care about them at all, you are doing something wrong. Your baselines and branches are identified by tags. If you understand how the CVS numbers work, they are actually quite logical; there are reasons why they work they way they do. It's not play ``games''.
Version numbers *are* meta-information, so it's meaningless to talk about them being overloaded with metainformation. They are not intended to correspond to your product release numbers, which are usually the fabrications of a marketing department anyway, like e.g. Solaris 7 being the followup to 2.6. Do you think the Sun guys bumped up their version control system to use the number 7? ;)
How about polyfork?
... as one can spoon changes back into whichever tree one is following, knife out other changes, and fork the system themself if they wish.
Silverware would be a better name
Seriously, this wouldn't give equal weighting to every trivial disagreement any more than free source code does anyway. Whether the control system is subversion, cvs, arch, or plane ole text files, we as individuals choose which fork we want to follow. Indeed, currently the mechanism in use is ftp (or alternatively http/rsync), ie. do you ftp linux-2.4.17.tar.gz, linux-2.4.17-ac3.tar.gz, or linux-2.4.17-myfork.tar.gz. Your decision is based on your trust of Linus, Alan Cox, or myself (probably nil). Using arch wouldn't change this, it would merely give you more flexibility in choosing bits of the Linus kernel, bits of the AC kernel, etc. in creating your own, personal fork that reflects your values and interests, and if others like your choices, they can benefit as well. If they ignore your choices, then who cares? You still benefit in having been able to make and prosper from your choices yourself.
How on earth could that be a bad thing?
That having been said, my wishlist would be support of gnupg signatures and authentication and scp instead of ftp. As to it being written in a shell scripting language, so what. If you really want to run a client or (god forbit) a server under Windows, there is nothing preventing you from writing a compatible client or server in the programming language of your choice (although the mockery one would receive for having used Visual Basic would probably detract some from the feeling of accomplishment, but I digress).
The Future of Human Evolution: Autonomy
I'm sure that down the road it would be a very slick thing to the rsync protocols for data transfer between sites, as implemented in rsync and Unison. That would provide all sorts of ooey-gooey- encrypted, compressed goodness to help network connections be used more efficiently.
The file transfer protocol isn't nearly as important as how it deals with versioning, logging, and thie likes, to be sure...
If you're not part of the solution, you're part of the precipitate.
The standard that SCO, Solaris, and *BSD can probably all conform to.
With its POSIX subsystem.
With its POSIX subsystem
With BSD underneath.
I suppose Tandem may not be emulating a flavor of Unix, but who's got one of those at home? PalmOS isn't a Unix-like system, but it's getting pretty long in the tooth, and isn't a tremendously viable platform for arch anyways.
It's not outrageous to suggest that Unix has effectively "won" the mind-share war.
If you're not part of the solution, you're part of the precipitate.
Whether or not you use a standard client or server, the protocol itself is flawed. It sends passwords in plaintext.
True, implementing an extremely simple FTP server might avoid the buffer overflows in standard stuff, but it couldn't solve that problem.