Rails has a nifty script and rake task to generate snapshot gems from Subversion and push them to a gem server.

Actually, the freebsd ports and packages system is all cvs based, and the preferred tool for working with it is ruby based.

I dunno about the ‘easily’ part though, because the ports system seems to be a fairly massive make hack.

But it does have the kind of behavior you’re talking about. FreeBSD ports pull source directly from a list of master sites that the port author puts in the makefile, which is quite verstile. If you’ve authored a port, you just use a command line utility that bundles up all the required skeleton info and sends it off to the master ports repository for approval.

But really the ultimate hack would be what you’re talking about. A central gem tracker that can pull any tagged version from the authors source repository, or even the ‘head’ or ‘current’ as a gem. It sounds like rails folks have already implimented the first bit using a push model.

Actually, for a while now I’ve thought that there’d be a lot of merit to a ruby specific revision control system. Being syntax and semanticly aware could enable a lot of snazzy things. But that’s a much bigger and unlikely idea ;)

Zed A. Shaw’s FastCST? :)

How about implementing a feature similar to seaside halos but tying it to a cvs or svn backend, so that your rails application has it’s own builtin source code repository, that can be edited through the web?

gab: FastCST looks interesting, but no, that’s not the sort of thing I’m imagining. FastCST just happens to be implimented in ruby, otherwise, it’s a fairly standard distributed approach: changesets have a UUID , you can assign an arbitrary site specific revision number to some sequence of applied changesets. Changesets get arranged in a dependancy tree of UUID ’s.

Right now it doesn’t allow conflicting applies at all… but when it does, it’ll be strictly manual mergeing. This is because, like almost all diff mergeing tools, it’s not aware of the syntax and semantics of the language.

Darcs gets a bit this by exploiting some algebraic properties. Which is also unforetunate because it creates a lot of overhead as well.

But instead, if you were aware of the syntax and semantics of the language you were working with, it would make automatic merges consideribly better. There’s also oppertunities to do things like reformat someone elses patch into your preferred coding standards, etc.

well, I was thinking of how FastCST should allow you to use plugins. This way you could add a merging tool tuned for the choosen language, and still rely on the rest. But maybe I just need to sleep :)