Subversion Hits Alpha

C. Michael Pilato writes: "This overheard while eavesdropping on announce@subversion.tigris.org: Gentle coders, The ever-growing cadre of Subversion developers is proud to announce the release of Subversion 'Alpha' (0.14.0). Since we became self-hosting eleven months ago, we've gone through ten milestones. This milestone, however, is the one we've always been working towards; it's a freeze on major features for our 1.0 release. From here out, it's mostly bug-fixing. We hope this announcement will lead to more widespread testing; we welcome people to try Subversion and report their experiences on our development list and issue tracker." Subversion, a source control system akin to CVS, has been in the works for a couple of years now.

Comments

Re:while we're at it, let's burn our Makefiles too

[smagoun]

...and there's always ant, from the folks over at jakarta.apache.org. It's aimed at java development, but can be used with other languages as well.

Ant has some pretty cool features (and a few misfeatures, sadly), but it's really caught on in Java-land.

I've been using Subversion for three months...

[Ludwig668]

... and have been really happy with it. Setting it up is a thesis project (the most common problem with software that's free) but once that was done, it works beautifully.

SCC works well for several purposes:

• Backup--I save everything in a personal 'svndocs' directory; including stuff like quicken databases, word documents, all that stuff. Just 'svn commit' (or in my previous life, 'cvs commit') and you have your backup stored on another computer. I had a laptop die at a customer's site, and it took downloading the client and 20 minutes to resume development on another computer. My brownie point score soared.
• Share files with customers which are far away. SCC acts like a low-bandwidth file server. There are suddenly no hassles putting together installers and such; so the rate at which you can deploy updates greatly increases. CVS really sucks when it comes to directory versioning, that's why I switched to SVN. I can now configure the whole deployment tree on my side, and don't have to start e-mails with 'well, because CVS can't do this, you need to delete the whole project and check out over again.' Monkeying around with directories is much more important, considering the way that ant relies on java files being in directories which correspond to their package names.

Re:arch vs Subversion

[millette]

Seriously, if we had a good enough filesystem, there wouldn't be a need for any db. It's only a question of point of view. You mention using standard database tools to manage subversion. What's so wrong about standard filesystem tools to manage arch then? You know, like cat and grep, and ls even. (Please, don't point out that grep isn't a filesystem tool, please).

Re:In 20 words or less.

[ftobin]

CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password) as its communication protocol. It's not even encrypted.

Noone in their right minds uses this.

The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access.

It's a 'kludge' that works extremely well, and fits well into the unix philosophy.

It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that.

False. It requires that they have an account on the system, not one necessarily that allows you to execute a shell (just like SourceForge has it set up).

Since CVS stores each file independently, you can at least say they don't have access to a module but you can't say they don't have access to a certain branch. And you certainly can't say something like "they can't delete/modify existing revisions".

True. But this has little to do with the transport protocol.