Results tagged “Subversion” from Mechanix

There is no project so small, so trivial, that it is not worth you putting it into a Subversion repository. If it's worth your time to work on it, it's worth saving. Putting it in Subversion is a matter of a few statements, and you don't have to do any big fancy-shmancy server setup.

Let's assume you're working on Linux/Unix, and you have svn installed, which is pretty standard these days. Say you're working on a game called bongo, and you've just been keeping it in ~/bongo. Do this:

# Create the Subversion repo
$ mkdir /svn

# Create the bongo repo
$ svnadmin create /svn/bongo

# Import bongo into its project
$ cd ~/bongo
$ svn import file:///svn/bongo -m'First import of bongo into Subversion'

# Move the original bongo directory out of the way,
# in case something goes wrong
$ mv ~/bongo ~/bongo-original

# Check out bongo from Subversion
svn co file:///svn/bongo

At this point, you'll have a checked-out version of bongo in ~/bongo, and you can make commits against it.

Ricardo Signes points out that Git makes it even easier.

# Go to the bongo directory
$ cd ~/bongo

# Import bongo
$ git init

With Git, everything is put in your ~/.git directory, and you don't have to check out anything from the project.

Whatever route you choose, version control is so simple these days there's just no excuse not to do it. Your programming life will never be the same.

Ben Collins-Susmann writes about the 80/20 split of programmers and how the 20% of programmers who are "alpha programmers" have to account for the 80% who are not, and how they use their tools.

Although the post talks about Subversion and distributed VCSes, the lessons hold for those who use Perl, too. How many programmers have we worked with who don't know about CPAN, or are afraid to use code from CPAN? How about programmers who don't understand the internals workings of "standard" Perl objects (i.e. blessed hashes), who don't realize that a {} is an anonymous hash constructor, not a "class" or "object" constructor? Or who are afraid to use the map and grep constructs?

On the flip side, you don't want to dumb down your code to the lowest common denominator. Although both Mark Dominus and chromatic have written about it recently, I like Randal Schwartz's phrasing best: "Sooner or later you're going to have to write in Perl." I'm dealing with PHP code at work where the original programmer did not use keyed lookups (PHP arrays are effectively ordered versions of Perl hashes) to check to see if a given string was in a list of special strings. I'm assuming that he was unaware of the ability to look up array elements by key, but I think it would be even worse if he specifically didn't use the feature out of fear, or worrying about future programmers not knowing what the code did.

Assuming that you're a 20% programmer (and that you're reading a programming blog suggests that you are), how do you deal with 80% programmers? Any tricks for the rest of us?

Addendum: Not five minutes after I posted this, I found this article "What if powerful languages and idioms only work for small teams?", with most of the value in the comments from readers.