Latest News >> 2008-07-20 2008-06-25

I’ve been completely fed up with news/feed/rss/atom readers these days. I use Linux as my primary operating system, and I only have a few feeds that I want to rip through quick so I can get to reading the content. Yet, trying to find a reader that doesn’t suck donkey balls has been a chore.

2008-06-21

Wanna know what all the Ruby vulnerabilities are? Or at least have a fun look at how to search through code for clues? It’s a blast.

2008-06-13

I’m dropping a large blog post on everyone to just say that I haven’t died, I’ve just been busy working on my book for A/W about Mongrel. I had contracted with them to do a book about deploying Mongrel, but then decided it wouldn’t be a very good book since we’d already done one about that topic and there wasn’t too much more to say.

Motivation

1.1. Another Revision Control Tool?

Yes, another one, because I have some new ideas and would like to try them out. The original ideas and information from the C version are at the old C version’s page. It lays out a lot of the reasons and philosophy behind it all.

The main thing that does/will make FastCST different is that it will focus on security up front, be completely decentralized, easy to use, and fast as possible. The novel thing about it is that the delta algorithm uses a suffix array to do its work which is incredibly simple.

One important goal of FastCST will be to not depend on a particular language. All file formats and transmission protocols will be documented and accessible to other languages.

1.2. Why Ruby?

Ruby is probably the most productive language I’ve used in a really long time. The core functionality of the current release (0.6.5) measures in at an incredibly light 2522 lines of code (minus comment). The most amazing thing is that I started the project the last week of Feb. 2005, which means I implemented all of the original C version’s functionality and a whole lot more in about 1 month. I worked on the original C version for close to a year.

1.3. Why GPL?

I want to be famous, and that’s hard to do when some company takes my stuff, re-brands it their latest Foo-Tronix Confabulator, and never gives me anything in return. Other folks are free to do whatever they want under the GPL restrictions, and I’m a pretty flexible guy so I’d probably let someone take code if they asked.

I also think the GPL fits the spirit of what I want to do with FastCST. It lets people use it for free, and they can do what they want with it, even modifying it for their own usage or internal usage. They only need to hand me or make code available if they distribute it under the GPL themselves. In the end everyone’s happy.

The only exception to the GPL is if you write FastCST plugins then you can re-license them under any license you want as long as they don’t contain code I’ve written. This means you can write a FastCST plug-in that uses/links to the ChangeSet and Repository modules, and then distribute that separately as a BSD licensed or commercial licensed work. If you cut any code out of my other commands then you have to license the results GPL to distribute.

Not all of the code packaged with FastCST is GPL though. The suffix array code backing it is licensed under the Plan9 license and everything is included there. Also the software directory has a lot of software that is used. Those portions are licensed by their authors so I can re-use them, and are not owned by me at all.

1.4. Why do you pronounce it “fascist”? That means you worship Hitler right?

Originally it was just easier to say “fascist” than “fast see est tee” and it also summarized what I wanted from a revision control tool: Complete and ruthless control over my source. The irony of it was, by giving everyone the ability to trade changes freely-yet still control their copies-FastCST liberated people from fascism present in many development processes.

But, some people just don’t get irony and humor. Calling the project “fascist” is actually meant as a dig on other centralized control systems that are designed for developers by developers so they can enforce their obnoxious fascist policies on people. I’m a developer and I’m sick of this. I don’t think developers are evil or doing this intentionally, I just think they have limited tool choice and were “raised” to think they were the gods of the process.

The original reason for starting FastCST was to break the developer strangle-hold on the development process and make it equitable and democratic for all participants. This comes from my core belief that the era of Super Star developers is over, and the only way we can move forward is to create an equitable and social development model that allows everyone involved in the development process to be a peer.

If I continue to have people refer me to wikipedia then I’ll probably have to change the name. Any time you get associated with Hitler you’re done. Just to set the record straight, I am not a supporter of fascism, or any form of totalitarianism. I believe that all forms of government with any control over the citizenry eventually devolve into either authoritarianism or totalitarianism—even socialist Europe and democratic America. The point of FastCST is to break up fascism and help people. The point of the name is an ironic joke.

2. Functionality

2.1. Does it support merging yet?

Yes and no. As of the 0.6.5 release FastCST will merge without any problems on the changeset level. This means you can be in just about any part of the revision tree and merge any other revision you want. You need to begin a new revision before doing this since you are effectively editing your current source.

The only limit right now with merging is that it will refuse to merge anything with conflicts, and there’s no way to resolve them. A work around is to copy your current directory somewhere else, use undo and apply until you get to the revision with the conflict, and then resolve it your self. That’s ugly as hell and not the planned conflict resolution method at all. I’m working on the actually conflict resolution code as I write this. Well, not as I write this, but when I’m done I’ll…oh you get the idea.

2.2. What?! Merging doesn’t resolve conflicts?! What crap!

You’re right, that is crap. That’s why I’m working on the conflict resolution right now. Don’t you read? I just said that in the previous question. Oh, you must be a slashdot patron.

2.3. How will conflict resolution work in the future?

Everyone I talk to seems to say they don’t want FastCST to do the file level merging itself, and to punt to the developer on all possible conflicts. This is the way I prefer things as well. I hate having to dig through directories looking for .rej files or ”>>>>>” crap in my files. Also, everyone has their own favorite diff/merge tools and there’s no way I’m going to beat them.

One thing that people don’t seem to understand is that automated diff merging is doomed to fail in almost every case. The main reason is that diff relies on lines as structure but your favorite parser relies on a grammar to structure a document. This means that, until you can parse every file, you’ll never get an accurate merge without human intervention. It may work for trivial changes, but I (and others) would rather be involved in the process to be sure.

2.4. Will you be able to merge PNG files?

The actual question is usually, “Will you be able to merge Microsoft Excel files?” When I ask the same question back with PNG files people usually go, “Oh, that’s stupid how does the program know what a PNG file means?” This is exactly the problem with merging: The computer is now trying to get into the meaning of the data rather than the structure. The more complex the data, the more complex the meaning, the more impossible the merge.

Developers typically work in this lush fantasy world where they can do merging since they use source files that are pretty flat in structure. But, even with this clean playing field merging fails more often than not without some human interventions. Again, computers are really miserable at meaning, so there’s no way a diff tool that works on lines will work very well with a source file that is parsed into a grammar. Just try diff on an XML that isn’t canonicalized and you’ll see what I mean.

I chose to go in the other direction with FastCST. Since computers suck at determining the meaning of anything, FastCST tries to behave consistently but incredibly stupid. Since it doesn’t know anything, it punts to the developer whenever it does something that might get it into trouble. This approach makes it much easier to implement and get right, and turns out to be closer to what most people want.

2.5. How does FastCST manage revisions/changesets so they don’t conflict?

That’s easy, each one is given a UUID/GUID and those are used for all references such as parent/child relationships and merge references. But, since people are really bad at huge numbers, it lets you set an arbitrary revision name and you can use both in most commands. This does mean that two people could make a 0.5.3 release with different stuff in it, but they will be unique by their UUID so all is good.

3. Usage

3.1. What commands does FastCST support?

  • abort—Aborts an in-progress current revision
  • apply—Applies a child revision to this one (use list first)
  • attach—Attaches a file to the in-progress revision (experimental)
  • begin—Starts a new in-progress revision
  • disp—Adds a disposition line to the in-progress revision
  • env—Searches and updates the environment
  • finish—Finalizes an in-progress revision putting it in the repository
  • get—Gets revisions from someone else’s repository via a URL
  • index—Creates and searches a source content index (experimental)
  • init—Initializes a new repository in the current directory
  • list—Lists revisions and/or your current position in the tree (think ls)
  • log—Adds a log line to the in-progress revision
  • merge—Merges another revision to the in-progress revision
  • publish—Publishes your repository to an FTP site
  • read—Reads revisions out of your pending mail box (after a recv)
  • recv—Receives revisions from POP3 and puts them in your pending mail box (use read)
  • send—Sends a revision to someone else over SMTP
  • serve—Fires up an embedded web server so you can server your repository directly without FTP (read only)
  • show—Shows a particular revision or the current in-progress revision
  • status—Gives a quick or full (-f) status of the changes you’ve made and whether you’re in-progress
  • undo—Undoes the last apply. Use abort if you’re in-progress.

4. Installation

4.1. I get a “permission denied” when I run rake. Do a “rake clean” first. Not sure why this happens.

4.2. What do I need to install for Debian?

The build has been tested on ArchLinux and Debian, but to get it to build or work under Debian you’ll need to do some magic apt-get work:

  1. Remove anything remotely related to ruby. The package layout changed recently so this is necessary to get it to reinstall correctly.
  2. apt-get install ruby (not ruby1.8). If you’re on the right version of Debian (of the 100) you should get the 1.8 stuff with all the goodies.
  3. Finally make sure you have these packages as well:
    1. rake
    2. ruby1.8-dev (yes, specify the 1.8 this time)
    3. libtest-unit-ruby (no 1.8 this time)

Once you do this you can then use the “rake” command to build everything and get your stand-alone build/fcst script.

4.3. Do I have to use your pre-built script?

Nope. Read the README . That’s why it’s called a “read me”. So you’ll read it. ‘Cause it says, “read me”. Get it? It wants you to read it. Neat how that works, eh?

4.4. Do I have to install your stuff in my Ruby install?

Nope. Read the README . That’s why it’s called a “read me”. So you’ll read it. ‘Cause it says, “read me”. Get it? It wants you to read it. Neat how that works, eh?

You must be a slashdotter ‘cause I just covered this.