Slashdot Mirror

Also, you're getting ready to do the switch. :)

Sorry, I don't know of any public SVN repository using ViewCVS. However, installation and configuration of ViewCVS to use SVN is really very easy; if you're curious, I encourage you to set it up and play with it a bit.

I've been doing the exact same thing you are over the past couple weeks, and it took me about 15 pages of documentation on lock-modify-unlock and copy-modify-merge (with branching) to get to where I believe I can convince everyone that Subversion is better (plus a good 50 pages or so on how to use Subversion). Start with the beginning of the Subversion book--it explains things well.

Also, assuming you use Windows desktops, use TortoiseSVN.

configuration and maintenance is a breeze.

No discussion of Subversion is complete without a considering the relative merits of the two types of the repository storage system, Berkeley DB and FSFS.

The Subversion book at red-bean.com has an informed discussion in Chapter 5.

It appears that FSFS, which is basically the regular file system like CVS uses, is better in every way. The books says, "In theory, it promises a lower barrier to entry for new administrators and is less susceptible to problems." New administrators should take note because diagnosing and repairing problems with the Berkeley DB and Managing Disk Space is a whole other level of skill compared to administering CVS.

Unless you are going to administer a huge project, in which case you should NOT be a new administrator, the Berkeley DB offers nothing but potential headaches.

configuration and maintenance is a breeze.

No discussion of Subversion is complete without a considering the relative merits of the two types of the repository storage system, Berkeley DB and FSFS.

The Subversion book at red-bean.com has an informed discussion in Chapter 5.

It appears that FSFS, which is basically the regular file system like CVS uses, is better in every way. The books says, "In theory, it promises a lower barrier to entry for new administrators and is less susceptible to problems." New administrators should take note because diagnosing and repairing problems with the Berkeley DB and Managing Disk Space is a whole other level of skill compared to administering CVS.

Unless you are going to administer a huge project, in which case you should NOT be a new administrator, the Berkeley DB offers nothing but potential headaches.

http://svnbook.red-bean.com/en/1.1/ch02.html

http://www.accurev.com/accurev/info/timesafe.htm

Clicky: Version Control with Subversion

I've read the free subversion PDF, and I was interested enough to install it for use at home on my Windows box. The PDF does a great job of describing subversion's revisioning system, which is based on tracking directory revisions rather than file versions. That's great and all, but I've never read a valid explanation as to why this is a better way to do things than the way VSS and CVS work. VSS and I think CVS also use file revisions which makes it super easy to look at one file's revision history. With Subversion, how is it beneficial to have a file that hasn't changed have its revision number incremented on every check-in? Doesn't that make it very difficult to track changes to one source file? Does the Pragmatic Programmer book delve into source control theory at all?

The Subversion Book seems to have most of what you need to know and its free as in speech and beer.
from the review it does seem to have a couple of chapters about general project organization that aren't in TSB. Otherwise it the list of topics seems to be right out of the oreilly book.

I have yet to actually use SVN, but I'm soon going to as a new project I've joined use it. From the description I got it was CVS but with the biggest "gotchas" fixed. As other people in the thread mentioned it is very easy to migrate for developers.

We got a tip that there is a good book on SVN out from O'Reilly (who else?) and it's also available online, for free Version Control with Subversion.

BTW the project I joined is hosted on BerliOS.de which is a Sourceforge like system which supports SVN for hosted projects (another added feature over SF is Wikis). AFAIK it uses the same system as SF so they are very similar.

If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. Its peculiar character, too, is that no one possesses the less, because every other possesses the whole of it. He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement or exclusive appropriation.

Inventions then cannot, in nature, be a subject of property.

The CVS Book is a free download. You can order a dead-tree version, as well.

When accessing subversion using web-dav, you must run Apache 2 as documented here [big page]

Using web-dav and subversion is a must if you need firewall transparency. Although I found that the http sniffers on my corporate network actually slowed down my repo so I use svnserve instead (no apache / web-dav needed)

The good news is that the underlying architecture should be portable to other storage types, and this is supposedly going to be coming eventually.

Actually there's already another storage type in 1.1.

1: How do I convery my existing system? Any chance of a link.

Read the Subversion Book

Note the "svn dump" and "svn load" commands. "dump" will serialize your database into a text representation. Then reconfigure your server, and use "load" to incorporate all the data into your new database.

From what I know of the open source world, documentation is one area that people make money on the free product.

From what I know of the open source world, documentation is one area that people make money on the free product.

...the free, online version of the O'Reilly subversion book.

The documentation is not lacking, people are just too damn lazy to google for it or follow the links on the subversion site at tigris.

There's a free online version of O'Reilly's Version Control with SubVersion

Lies, Damn Lies, and possibly true
1)Branching: svn doesn't copy the entire tree - making a branch is instantaneous, lightweight operation. http://svnbook.red-bean.com/svnbook-1.0/ch04s02.ht ml#svn-ch-4-sect-2.1 see the section on "Cheap Copies"

2) This is just pure and simple BS. svnserve.
http://svnbook.red-bean.com/svnbook-1.0/svn-book.h tml#svn-ch-6-sect-3
If you can run cvs on the machine you can run svn.

3) On large, extremely large repos's, maybe but svn gets faster all the time. On my repositories it more than fast enough.

Just because some one says something doesn't make it true. And don't go on just my word, do your research.

Feel bad that you are stuck with M$-$$ what a piece of crap. When svn became self-hosting I switched from $$ to svn and have never looked back.

Lies, Damn Lies, and possibly true
1)Branching: svn doesn't copy the entire tree - making a branch is instantaneous, lightweight operation. http://svnbook.red-bean.com/svnbook-1.0/ch04s02.ht ml#svn-ch-4-sect-2.1 see the section on "Cheap Copies"

2) This is just pure and simple BS. svnserve.
http://svnbook.red-bean.com/svnbook-1.0/svn-book.h tml#svn-ch-6-sect-3
If you can run cvs on the machine you can run svn.

3) On large, extremely large repos's, maybe but svn gets faster all the time. On my repositories it more than fast enough.

Just because some one says something doesn't make it true. And don't go on just my word, do your research.

Feel bad that you are stuck with M$-$$ what a piece of crap. When svn became self-hosting I switched from $$ to svn and have never looked back.

Hmm, I found the following from Karl Fogel's The Promise of a Post-Copyright World as yet another perspective on this:

Although the free stream does not use traditional copyright, it does observe, and unofficially enforce, a "credit right". Works are frequently copied and excerpted with attribution -- but attempts to steal credit are usually detected speedily, and decried publicly. The same mechanisms that make copying easy make plagiarism very difficult. It's hard to secretly use someone else's work when a Google search can quickly locate the original. For example, teachers now routinely do Google searches on representative phrases when they suspect plagiarism in student papers.

Of course, in this case, anyone can just click "parent" and find out who really wrote the post you copied, so it's even easier.

Song of the piracy apologist:

(1) I do not believe in copyright laws

If you agree with this, feel free to repost it in the future.

Song of the piracy apologist...

(#1) I do not believe in copyright laws.

You should read the CVS book: http://cvsbook.red-bean.com/cvsbook.html

In short, with CVS you check out files from the repository, work on them (edit, compile, test, whatever) and when they are in a suitable state you check them back in (commit) which causes the version number associated with each file to automatically increase. If your working dir is in a particularly interesting state, for example a release version, then you create a "tag" which saves that state, essentially remembering the version number of each file for the current configuration.

As far as automatically-generated files, the standard practice is to not keep them in CVS. So say you have foo.sh which creates bar.c and baz.c. You add code to your makefile so that it knows that if bar.c or baz.c need updating that foo.sh is to be run. foo.sh is kept in the repository and is versioned, but bar and baz are not, they are just regular files in the working directory. When you start with a fresh checkout they will not exist, but when you run make they will be generated. Typically each developer maintains his/her working directory so it's not like these files need to be created every time. Essentially, you don't keep autogenerated things in the repository because they can always be generated in your working dir. If the generation is not automated then you might choose to include them, however.

CVS is generally intended for text files, but it can also be used with binary files but it will be inefficient. Don't store large binaries in the repository, if possible.

no you're right.
http://svnbook.red-bean.com/svnbook/ch01s02.html

As another user pointed out, you don't need to have Apache 2 running as your webserver if you want to access Subversion. You can do one of the following:

• Run Apache 1.x as your webserver on port 80, and then have Apache 2.x running side-by-side as a separate server and have it listen on port 3690, the port that IANA has reserved for the Subversion protocol.
• Instead of Apache, run the lightweight Subversion server svnserve. It's quite simple to set up compared to Apache, but can only grant blanket read/write permissions. Also, you can't fine-tune permissions on a per-directory basis like you can with Apache.
• If you have pre-existing accounts on your system, you can tunnel through ssh via the svn+ssh://host/path/to/repo pragma which will authenticate itself via ssh and use the Unix file permissions on the repository.
• If you are the only one accessing your repository, you can even use the file:///path/to/repo pragma and forego a server altogether.

Thomas

I'm not sure that being able to edit the ,v files by hand is an advantage of CVS. If anything, I see it as a disadvantage since: a) you're making changes "behind the system's back"; and b) it's easy to screw up.

The face that Subversion uses a Berkeley DB file backend doesn't mean you're hosed in case of problems, especially if you've been backing your data up. You can make a live backup anytime you want - with every commit, if you're paranoid. It's also possible to dump any or all commits to a human-readable format that can also be used to restore. But usually you won't even have to muck around with restoring from backup - if the repository gets wedged somehow, try 'svnadmin recover' and it will usually solve the problem.

There's a nice chapter in the Subversion online book that deals with all this stuff.

Database & log files take up a LOT of space.

svnadmin comes with a command that you run on your repository called list-unused-dblogs, it will tell you what Berkeley DB log files are unused, which you can then delete. But usually people will want to just run:

svnadmin list-unused-dblogs repository | xargs rm

Quite hard to share repositories

Decentralized repositories is one feature Subversion does not have (yet). But take a look at SVK which is what the Subversion developers currently recommends to anyone looking for this feature.

No way to mark your branches (if you accidentally check out the directory containing your branches, you just got 50 gigs of 99.9% identical files...)

Which is why the current best practice is to lay out your repository like this:

/
/trunk
/tags
/branches

You did read the online Subversion O'Reilly book, didn't you?

No distributed development

I don't know what you mean by this, and how it differs from your "shared repositories" point above. Can you disambiguate?

Thomas

Look here...

Ever tried setting up a WebDAV server? That fits anybody's definition of hard.

I strongly disagree. Setting up a Subversion repository to be accessible over the 'net was PISS EASY, even for me, a first-time user. You can use the included light-weight server (svnserve) or Apache2 if you need options like complex authentication. It's very easy to set up and very nice to look at if you enable XML output. :)

There are howtos in the Subversion book. Happy reading.

The Subversion book mentions that you need to set the umask, something that svnserve doesn't do automatically. It was discussed on the dev list, but dropped because it was felt that setting a umask was an access-dependent thing to do, and as such should be left to the repository administrator.

More info at http://svnbook.red-bean.com/html-chunk/ch06s05.htm l

If you use Apache to network your Subversion repository, you can leverage all of the access control mechanisms that Apache already provides. Basically you can do per-directory access control for Subversion in the same way you'd do it for standard directories on a website.

Using Apache also allows you to leverage SSL, wire-compression, etc, etc, that the basic svnserve server doesn't support. svnserve is still a good starting point for most organisations however -- over a LAN where you don't need encrypted traffic and basic username/password authentication will do.

More info in the book, as always: http://svnbook.red-bean.com/html-chunk/ch06.html#s vn-ch-6-sect-1

I've been using svn for years. Shortly after Sept. 11, I took a flight. The name of the Subversion book used to be "The Ultimate Guide to Subversion". I got more than a few looks while reading it in the airport!

Informative? How about -1, misleading.

Subversion does NOT require Apache! It can use Apache, which is useful in some cases, but it also has a stand-alone server.

Berkely DB is a transactional database; it will not necessarily work properly if multiple processes are accessing it at the same time.

For more details, check out the subversion book, chapter 6.

The solution is to drop svn+ssh, and run svnserve.

There seemed to be several helpful replies to this, but I didn't see anyone linking you to the book, so there. It's good.

The main site seems to be slashdotted. There appears to be an online book on the subject here

Version Control with Subversion
Draft Revision 8770
Ben Collins-Sussman
Brian W. Fitzpatrick
C. Michael Pilato

-jim

Nothing new here :-(.

Copyright law has been extending its domain since its inception. This process has been driven by corporate interests -- not, as the RIAA would have you believe, by creators and artists trying to "protect their rights".

If, even after the RIAA lawsuits and now this, you still think that copyright is basically a socially good idea that just gets taken too far sometimes, please see

http://www.red-bean.com/kfogel/writings/copyright. html

for a possibly eye-opening history (and a blueprint for change).

Best,
-Karl

I thought it was cool how no-one really knows what the F stood for anymore, and to make it stand for "Feline" just because some of the developers have cats? That's just daft.

If you can't get hold of whoever came up with the original name to ask them what it was you shouldn't make it up in their absence. They created and named the project and you should respect that.

By the way, FVWM's a good and very configurable wm. However, as a result of being so configurable it's codebase has to support loads of options and is big as a result. Personally I prefer the smaller window managers such as aewm and it's derivatives.

Open Source Development with CVS by Karl Fogel is a great online CVS manual and reference. I use it all the time.

JP

I bounce back and forth between lwm for its ease of use and aewm for its appearance.

Don't know about fvwm, but you're not the only one using a lightweight window manager. Check out aewm. There's also some links to aewm derivatives on that page if you're looking for interesting wms to play with.

Here's a couple of decent ones:

http://cvsbook.red-bean.com/

http://www.pragmaticprogrammer.com/starter_kit/vc/

As for online resources, a good place to start is probably the cliki, a CL-related WikiWeb with emphasis on free software.

There are some free online books, like Successful Lisp, Loving Lisp - the Savy Programmers Secret Weapon, or Paul Grahams On Lisp (which isn't really a beginners book, but very enlightening once you are familiar with the basics). The Common Lisp Cookbook is not as big as it should be, but does contain useful information, and is growing.

An absolutely invaluable reference is the HyperSpec, a heavily hyperlinked online version of the standard. You definitely need that.

You might also want to check out the comp.lang.lisp newsgroup, or the #lisp channel at freenode. Depending on your specific interests, the LispWeb or Clump mailing lists may be interesting, the first deals with web programming using Lisp (surprise!), the second with general application developers issues.

Last but not least, there has been a movement of Lispniks gathering to drink beer and talk about all things Lisp (and everything else) in the last months. Check out this site, maybe there's a user group in your area. The people I've met so far are generally a nice and interesting bunch, and won't bite you even if you don't know the argument lisp of update-instance-for-redefined-class from the top of your head.

Happy hacking!

However, those are largely things we don't control. The controllable factors of success are more interesting to me. I guess it's because there are lessons on software engineering here. Cool projects can be run into the ground, and tiny niche projects can do well if they're well-run.

Hands down, the best nuts-n-bolts coverage I've ever seen on important issues to successfully developing open source is in a book by Karl Fogel, Open Source Development with CVS. Fogel's one of the developers behind CVS and it's planned successor, Subversion

The book is an interesting paradox: it has 1/2 the chapters GPL'ed. When I started working with CVS, they were useful enough that I bought our development team two copies of the book. Then I read the rest of it... and those are the chapters I'm talking about. Absolutely, they're the best summary of what it takes to successfully run a GPL-ish project. (Ironically, they've GPL'd the technical detail chapters and you have to buy the book to read the parts that talk about things critical to the success of an open source project).

Success is helped by things like doing lots of releases (seeing progress gets others to buy in, and not seeing progress leads to people quitting in frustration) and only adding features you need (let someone else add the features they need). There's a lot more here, but I'm not about to steal Fogel's thunder. Many of these are ideas that are effective in regular development, especially on custom coding projects within big companies.

The focus on GPL code is not the same as on shrinkwrapped products: you're not trying to add features just to add selling points. You're trying to get more people to use the project.

However, those are largely things we don't control. The controllable factors of success are more interesting to me. I guess it's because there are lessons on software engineering here. Cool projects can be run into the ground, and tiny niche projects can do well if they're well-run.

Hands down, the best nuts-n-bolts coverage I've ever seen on important issues to successfully developing open source is in a book by Karl Fogel, Open Source Development with CVS. Fogel's one of the developers behind CVS and it's planned successor, Subversion

The book is an interesting paradox: it has 1/2 the chapters GPL'ed. When I started working with CVS, they were useful enough that I bought our development team two copies of the book. Then I read the rest of it... and those are the chapters I'm talking about. Absolutely, they're the best summary of what it takes to successfully run a GPL-ish project. (Ironically, they've GPL'd the technical detail chapters and you have to buy the book to read the parts that talk about things critical to the success of an open source project).

Success is helped by things like doing lots of releases (seeing progress gets others to buy in, and not seeing progress leads to people quitting in frustration) and only adding features you need (let someone else add the features they need). There's a lot more here, but I'm not about to steal Fogel's thunder. Many of these are ideas that are effective in regular development, especially on custom coding projects within big companies.

The focus on GPL code is not the same as on shrinkwrapped products: you're not trying to add features just to add selling points. You're trying to get more people to use the project.

CVS, by comparison, is only accessed through the command-line client, so cvs gui clients have to execute the cvs binary and then parse the output, which as you certainly can imagine, is cumbersome.

Anybody who doubts this should try reading the source code to cvs2cl. All it does is build a CHANGELOG file based on the developer comments at checkin, so it should be pretty straightforward, right?

Not nearly. I wanted to make some other CVS reports; when I looked at all the rigamarole that cvs2cl has to go through, I just gave up. With enough time my brain could have handled it, but my stomach never would have.

1. Documentation is piss-poor. There's an easy solution to that one, but nobody likes writing documentation.

This is a modified orinoco_cs driver with firmware loader. It supports wireless extensions. I use it on i386 and ARM systems every day without any problems.