Slashdot Mirror

One way would be to figure out a way to decentralise the database. Rather than living on 350 servers perhaps it could live in 35,000,000 screen savers, all communicating peer to peer?

How? Beats me. Maybe start by experimenting with moving mediawiki's change tracking to modeled on Arch? Rendering a wikipedia article would then become an exercise in gathering all the necessary changesets from the P2P network. Instead of querying wikipedia's servers, you could just query your screen saver. Editing an article would consist of making a change then publishing the changeset on the P2P network.

Any other ideas? These are just random musings. There are plenty of people who are seriously studying this stuff.

And the best of all is that its not stored on some obscure RAID-less laptop somewhere. Instead it is stored on that secure, central server which all developer teams need to have. If you don't have one yourself, there are some Subversion hosting companies.

I sometimes wonder what would happen if GNUarch was merged with wikimedia. (And while we're at it, let's merge with BOINC as well! ;-) )

If you want revision control that's flexible network-wise, it doesn't get much better than Arch. You can use any filesystem for the repository that your box can see. NFS, FTP, HTTP, SCP, it's all good.

Want Python? Use Cannonical's implementation of the Arch protocol, Bazaar. It's got nummy Python goodness baked in, along with better support for digitally signed repositories (via GPG).

$DEITY help you if you want to use either on Win32, however. The Arch protocol requires both a real filesystem, and an OS that can use case-sensitive semantics properly.

Can anyone tell me if BitKeeper contains any innovations?

Not too much, I think arch (http://www.gnuarch.org/) and darcs (http://www.darcs.net/) were there first.

I'm also in favor of abandoning the term "innovation" in discussions of OSS. The concept "innovation in computer programming" was coined by Microsoft when they realized they hadn't any invention to speak of. McVoy using the same NewSpeak is kind of fitting.

While it may or may not have your personal favorite, this page compares the features of 13 different source control systems. I found it via this page that compared five of the more popular open-source systems.

There are lots of such tools, including CVS, Subversion (SVN), GNU arch, Monotone, Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Superversion, Codeville, Bazaar, Arx, and Bazaar-NG.

Subversion, of course.

Subversion, of course. What else is there? RCS? CVS?

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

There wouldn't even be much OSS (at least collaborative) without svn... OK, there is CVS but...

Wow, least insightful comment ever...

Subversion is trying, but it's at best a footnote right now; CVS firmly rules the roost (despite all it's problems).

Morever, Subversion isn't particularly innovative -- indeed, their stated goal is to provide a conservative update to CVS (getting rid of CVS's more annoying problems while keeping the same basic model)!

If you want a truly innovative free-software source-control-system, check out GNU Arch or Darcs.

Some VC systems are slow also because they need to access the repository for every operation they do. Others maintain enough knowledge locally that they only have to access the repository very rarely. One such system is GNU Arch. I have used it for almost a year now and it is by far the best VC system I know. Granted, it is a bit rough on the edges and user-friendliness was nowhere near the developers' minds but when you know it well, it makes just about everything possible. Arch is by far the most flexible VC system I have used.

But the learning curve is pretty steep.

And the GNU people have run to Arch with the usual zealot flair. A good comparison can be found here.

There are many good reasons for contributors to merge their patches into the kernel. For one thing, it means you don't have to play catch-up with the kernel releases and manage the patch on top of it, ...

I like Subversion just fine as a "better CVS" but if you're looking for a better version control system altogether, I would look into distributed version control systems like arch, or if you're looking for something with a better learning curve, darcs is really cool, and is implemented in the glorious Haskell programming language.

Distributed systems like these have a lot of advantages over the CVS/SVN model.

For all the whining about the lack of a Windows port, there's amazingly few actual contributors.

However, he gives no details.

It's an non-technical article. If you want to know more: here and here.

But webmasters may soon deluge these handy tools with links back to their site, not to get clicks, but to increase Google page rank.

The Arch Wiki has sufferred several times from such vandals in the past few months. I'm sure other wikis have, too. They create links over single spaces or dots, so that casual readers don't notice them. Attentively watching the RecentChanges page is the most effective way to find and fight them, but this is tiresome. I guess many wikis will require posters to be authenticated soon, which is a blow in the wiki ideal, but not such a major blow. Alternatively, maybe someone will develop heuristics to fight the most common abuses (e.g. external link over a single space).

So, this is not new, but this is now news.

Just because one of the selling points of Arch (on a GNU site) is that BK is unfree doesn't mean that this is the extent of its usefulness. Go read up on the wiki or elsewhere.

You might note, by the way, that the gnu.org Arch site is not the primary Arch site (certainly not the most frequently updated), though that's the one linked by the article. (www/wiki).gnuarch.org are Arch's primary frontends to the world.

Just because one of the selling points of Arch (on a GNU site) is that BK is unfree doesn't mean that this is the extent of its usefulness. Go read up on the wiki or elsewhere.

You might note, by the way, that the gnu.org Arch site is not the primary Arch site (certainly not the most frequently updated), though that's the one linked by the article. (www/wiki).gnuarch.org are Arch's primary frontends to the world.

You can find it at pmk.sourceforge.net

Or else, you can have a look at A-A-P, by nobody else than Bram Moolenaar, the author of the One True Editor, a.k.a. ViM :-)

There is also Package-framework, by Tom Lord, the author of the infamous Arch SCM.

I was about to mention SCons, too, but other people already did (it always pay to check other comments just before posting, especially on /. :-)

To sum it up : there is no shortage of alternatives to the incredibly hairy Autoconf/Automake nightmare. The problem is, people are still using them for the very same reason they use CVS instead of Arch/Subversion, or Sendmail instead of Postfix/Exim : because they're considered ``standard'' tools, and people feel more comfortable with software they know to be used by plenty of other people (millions of programmers can't all be wrong. Can they ?). I really hope they'll stop making this kind of mistakes soon, so I won't need to curse them everytime I have to debug some Autoconf breakage...

"Microsoft uses DCERPC, an extension of TCP/IP, as a transport mechanism."

and this is relevant how?

it is *another* protocol in the sense that nobody would be running it if it weren't for Svn

WebDAV is an open standard that plenty of products support, including your precious arch. I'd hardly describe it as a lame duck.

Note that now they've given up on getting everyone to install Apache2 and use DAV/SSL, the recommended protocol is svnserve, which was invented from scratch.

do you have any idea what you're talking about, or do you just make things up as you go? they seem to still think that DAV is still an option. And how is it possibly bad that they give you the option of a standalone server (as well as tunelling via ssh, or filesystem access)?

the same Anon Coward

Subversion uses Apache2, which *is* a whole new server from what the majority of people are running these days

On one hand you're suggesting that people run thttpd and on the other you're complaining about switching to apache2?

Let me draw you a picture.

Subversion is capable of running over the local filesystem, just like arch. So you can use it that way for a single developer if you want. But the whole point of a networked version is that people who aren't on the same filesystem to share a code repository. If you had explored your own links you'd know that arch repositories can be accessed via a network as well.

Stop trying to claim that distributed operation is more secure because you'd be willing to use a distributed server in a different manner than you'd use subversion or cvs. They all do pretty much the same things, and have the same security downfalls. If you didn't want to run a network service you'd be more secure, but you can do that without 'distributed' versioning systems.

the same Anon Coward

These vulnerabilities are a consequence of an architectural security flaw in both CVS and Subversion: they require an active server that talks a complex protocol to an unauthenticated client.

Whenever you allow an untrusted client to control code running on your server, there is a risk of a compromise.

The distributed version control systems Darcs and Arch show a better way. Read-only access requires only some read-only files published over HTTP. Since most projects already have a web site, this means there is no increase in the network services that need to be offered.

Once those files are downloaded, the anonymous user can get updates, make their own patches, branch -- all the facilities allowed by anonsvn/anoncvs and more.

Is anyone else concerned about the apparent contention over BitKeeper mentioned in the article?

Yup. But then, that's a (heated) discussion which has already taken place / is already taking place in plenty of other forums. No need to bring it in here too.

(As an aside, I use Arch).

Could someone which is using bitkeeper
update this comparison with the bitkeeper data.

No, the BitKeeper license is evil. Go read it sometime -- it prevents folks from working on competing systems. This means that folks working on Free revision control (like me!) are substantially hampered if we want to also do some work on the Linux kernel.

Larry has also been known to change license terms specifically to force a particular user to upgrade to a more expensive license -- I was an employee at a Linux startup (MontaVista Software) when it happened to us. He's been known to spread FUD about Arch in public, and is otherwise not a very nice person to have as a competitor *or* a supplier.

Particularly given that Free alternatives to BitKeeper with history-sensitive merging and distributed repository support (the two features that make BitKeeper so powerful) are available, using BitKeeper is arguably much more destructive than it is useful.

That's not to say that BitKeeper is the only way to get that effect, however. GNU Arch is another distributed revision control system, and Free Software to boot.

"BitKeeper makes Linus 10x more productive" might be generalizable to "distributed revision control makes Linus 10x more productive" -- pity we don't have more sample data yet. :)

BK uses a more distributed development model instead of having one central server, which allows people to maintain their own version controlled source tree from which Linus (or anyone) can pull patches from. This is more like Arch or SVK than CVS or Subversion. Although in the end it performs a similar function, the difference is fairly significant.

I hope that instead of a save button, some programs will constantly save work and provide a timeline-like feature to go through all changes in the document if neccessary.

I use vim and RCS for this purpose.

RCS allows me to check in and out revisions, and each revision has a change log. I can roll back changes, check differences, and even make my own branch of a file.

Subversion, CVS, Arch and many others also can fill the same role. Heck, you can even make a directory named backup and rename a copy of the file to 'myfile_date'. The reason why I settled on RCS is that its relatively simple to use and its cross platform (Linux, BSD, Windows-via-Cygwin, etc). I've been tempted to adopt one of the larger revision control systems for additional features, but haven't gotten around to it.

As for Vim, its cross platform, rather full featured, and if the power goes out, I still can recover the file. Plus its easy to use with RCS through a few simple aliases and/or keymaps. There is also Gnu Emacs or XEmacs and a host of other good text editors.

Sure, there could be one program that would do both, but that wouldn't be as useful. The unix philosophy of "do one thing, and do it well" is less of a pain in the long run. This way, I can reuse my $editor_of_choice in many other unix applications - slrn, mutt, etc. If I had one integrated program, sooner or later I'd become fed up with one part of it or another, and I would be forced to continue using it.

Just my $.02.

YMMV.

One of the things I liked most about Xouvert is their use of GNU Arch for tracking their tree. As a changeset-oriented revision control system (as opposed to a snapshot-oriented revision control system like Subversion, or a POS excuse for a revision control system like CVS), Arch made perfect sense for a project that's maintaining a branch (or several branches) of a heavily-forked project: capable of providing not only the snapshotted state of each branch but also aware of (and, indeed, focused around) which patches made it in at each changeset (and therefore capable of history-sensitive merging -- applying the patches that make sense to a given branch, without trying to apply ones which have already been merged in).

I'm a bit disappointed that Xorg isn't using Arch as well, since it seems like the perfect tool for the job. *sigh*.

You probably mean the Y server, not X. And we're using Arch, not CVS.

Andy Suffield has been working on the project; he's got some stuff up at http://people.debian.org/~asuffield/.

By the way, the modifications to libiterm required to support Y have already entered Debian Unstable, so you don't have to install that seperately now.

The biggest downside to arch is user interface and documentation. I hate to say it, but it's true. Obscure error messages is one of arch's biggest problems, and command names and syntax are sometimes not consistent. Focus thus far has been on functionality; user interface cleanups will probably start in earnest after GNU Arch 1.2 is released, which shouldn't be too far off.

There is, however, a fairly decent Arch tutorial called "arch meets Hello World", and if you like wikis, there is a more or less official GNU Arch wiki. (Even if you don't like wikis, there's good information here.) Each tla command will give you short usage if you specify --help as an option, and more info if you give -H.

I was just rereading bits of this thread, and have a simple question: What is POSIX if not an OS abstraction layer? Isn't any sort of need to add additional abstraction on top of it indicative of breakage?

And btw, there's a native win32 port of tla; see here.

Well kind of. The Win32 page on the Arch wiki says "Arch was never intented to run on a non POSIX system. Don't except to have a full blow arch on your Microsoft computer."

The URL for cscvs, for those who are wondering, is http://wiki.gnuarch.org/moin.cgi/cscvs . You need to have GNU arch access to download the source code.

It has basically the same functionality as CVS, but is based on a BerkeleyDB backend instead of a simple filesystem approach like CVS. This means, among many other things, that you can move files from directory to directory and rename them without orphaning them.

Bogus. GNU Arch is based on a filesystem-based repository as well, but can revision file moves, permissions, symlinks, and so forth.

Further, even if the Arch tools were to disappear tomorrow, I could still retrieve the contents of my files using tar, patch and similar tools -- something I can't do with a tool that backends into BerkeleyDB. (Yes, call me paranoid -- but I don't trust my source to big binary blobs managed by the same library that's destroyed my RPM database so many times). The repository format is write-once, so the files in the repository, once created, are never overwritten or modified as new history is added (unlike CVS's ,v files or Subversion's database backend).

There are other reasons to prefer Arch as well, including distributed repository support, history-sensitive merge operators, and arguably superior core design.

Yes, I'm glad to look at SVN on its merits alone -- and while it's a huge improvement over CVS, I still find it lacking compared to the other modern revision control systems out there.

If you're looking at switching to a more modern RCS, please consider Arch as well.

More extensible? Bah!

Look at Arch. You can access your repository via WebDAV (and thus apache -- this time without any extra modules), or sftp, or ftp, or raw filesystem access, and adding more is as simple as adding a new backend to the pfs layer. I'm not sure how depending on WebDAV + a svn module for your server is supposed to be _more_ extensible.

Here you go, lazy ass

Why choose Arch
Arch Comparisons with other VC systems
Arch Wiki

Why choose Arch
Arch Comparisons with other VC systems
Arch Wiki

Why choose Arch
Arch Comparisons with other VC systems
Arch Wiki

Well, actually, I quite certainly *do* handle the bulk of my dentistry in-house (the general-maintenance bits, at least) and only outsource in the event that I've managed to get myself into a quite serious pickle requiring 3rd-party intervention -- something which hasn't happened since I had my wisdom teeth pulled. Likewise, I do my own general-purpose kernel upgrades/patching/minor bugfixes -- and haven't yet needed to go the 3rd-party-intervention route there.

On Debian, apt *absolutely* can upgrade your kernel and resolve dependencies automatically -- no settings changes needed. It's only Red Hat where they may (or may not) be -- I've never checked.

Hmm -- I'd never heard of QVCS before. Just curious -- are you familiar with Arch?

I wonder whether you really looked into Arch because saying it is a hack onto CVS can not be further from the truth. If Arch is close to something then it is BK as Arch is also a distributed SCM whereas CVS/SVN/Perforce are just centralised SCM.

I agree Perforce is nice (I'm been using it for 4 years now) but I'm converting everything to use Arch as the distributed nature of Arch makes it much easier to manage repositories in several places while having all of them synchronised.

Do yourself a favor and look again at Arch .

I do not know a single open source developer who has had trouble finding work even in the previous bad economy.

Actually, I've known two very skilled OSS developers who've had substantial trouble finding work within the last year or so. One of them is now employed, and I'm not going to identify him here. The other is Tom Lord, the primary author of Arch, a next-generation revision control system. (If you're thinking of switching from CVS to BitKeeper or Subversion, go look into Arch. Now). Tom's been out of work quite a good long while, despite being one of the best UNIX developer/architects I know. Part of this is his location in the Bay Area (indeed, I got him a job offer contingent on his willingness to move to Texas and he declined).

Anyhow, just because the economy's getting better in a lot of places doesn't mean that we're quite there to the point where anyone who does something valuable and is very good at what they do is employed -- but then, we're certainly getting back there.

yah, but finding people who know how to fix uncommon issues is a different thing.

Hire a good senior Unix sysadmin, and more than half the time you'll have someone who's also part systems-level programmer, part integration engineer, part deployment engineer, part revision control specialist, part... well, you get the idea. At my workplace the senior sysad is writing some in-house web-based user management software for HR, setting up several other departments with Plone-based intranet portals, and finishing the spit-and-polish on the automatic installation procedure he set up (grab a new machine, throw a CD in the drive and an ethernet connection in the back, turn it on, walk away for 20 minutes, and it's installed with all the software we use and configured for our network). He's showed up our Oracle DBA with regards to deep understanding why raw partitions are a useful feature (this included an in-depth discussion of the kernel's I/O elevator algorithm), personally wrote the drivers for the CD jukebox that was offered us for backup storage, is working on an embedded operating system in his spare time, and is otherwise a flat-out badass.

I'm currently the primary deployment engineer; I also sometimes serve as junior sysad (and was primary sysad before this guy was hired). A few days ago I wrote some in-house crypto-enabled backup software such that the business-type responsible for transporting materials to our off-site vault could burn their own CDs with our revision-control repository -- encrypted such that even should the CD (or the ISO it's burned from) be captured, there's no actual risk of data theft. Right now I'm at work (on a weekend) rewriting some integration code one of the application developers generated. I wrote the applet we use in-house for displaying the amount of time on a user's Kerberos ticket; In my spare time I also maintain some Free Software (which aforementioned lead sysadmin originally wrote) for converting CVS repositories to Arch format.

I've dealt with senior Windows sysad types on occasion -- and while they may be cheap, most of them don't have half the range of skills a good UNIX admin has. Hell, not even close to half.

I'll take good support at $.25 a dozen over someone who knows how to say "okay, reboot your machine... okay, we'll need to reinstall the OS" for $.10. (Further, given present economic conditions, Unix folks are much cheaper than was the case a few years ago -- indeed, if yer willing to deal with the new kids who just do Linux, I'd expect them to start getting cheaper than MCSEs real soon now... though you might not get quite the same range of skills and experience as the old UNIX longhairs in that case).