Related
I just read the Twelve-Factor App, which looks like a pretty comprehensive set of rules to apply in a web-based application. It uses python or rails in its examples, but never php... I was wondering which factors of the manifesto can be applied to PHP projects and how?
Thanks
Short answer:
All points apply to PHP as the twelve factor app manifesto refers specifically for web apps.
PHP has a very hard time complying to twelve factor, in particular in the items 2, 7, 8 9 (as a side effect of 7 and 8) and 12 (partially). Actually that's the first really grounded argument I have heard in the whole "PHP sucks" rant that is common on the Ruby and Python communities (don't get me wrong, I think Ruby and Python are better languages, but I don't hate PHP, and definitively hate the "my language is better" rants.)
Being that said, it may be that your PHP project is not a web app or SaaS, but just a simple website, so you may just deem that twelve factor is not a need.
Long answer: A point-by-point analysis would be:
Codebase: not an issue
Dependencies: the way PEAR works goes quite against this point, as pear dependencies are installed system wide and usually you don't have a consolidated manifesto to declare them. Is also usual for a PHP setup to require you to add packages to your OS installation to get some libraries available. Finally AFAIK there isn't a tool in PHP to provide isolation like "virtualenv", "rbenv" or "rvm" (or if it exists is not popular among the PHP community) Edit: Composer (http://getcomposer.org/) seems to do the right regarding dependencies, it still doesn't isolate the PHP version, but for all the rest it should be fine.
Config: some PHP frameworks are not very well suited to do this, but there are certainly others that do well, so it's not a flaw of the platform itself
Backing Services: shouldn't be much of an issue, despite maybe having to hack some frameworks a little in order to manage the services as resources
Build, release, run: this is totally appliable to PHP as this definitively doesn't concern only "compiling". One may argue that several projects and hosting platforms on the PHP community abuse of direct FTP, etc. but that's not a flaw of PHP itself, and there is no real impediment on doing things right regarding this item.
Processes: This definitively concerns to PHP. PHP is quite capable of running purely stateless processes (the emphasis is on the word stateless), and actually several frameworks make your life easy for it. For example, symfony provides out-of-the-box session management with memcached or database storage instead of regular sessions
Port binding: Over simplyfing it, this point basically demands you to reverse proxy and have the actual webserver embedded on the app instead of being a separated component. This puts PHP in a very hard position to comply. Despite there are ways to do this (see the reply about using PHP as FastCGI) that's definitively not the most common nor the best supported way to serve a PHP app as it is on other communities (e.g. Ruby, Node.js).
Processes: This is not impossible in PHP. However several elements put PHP in a hard position to comply. Namely the lack of good support for items 6 and 7; the fact that the PHP API to spawn new processes isn't really very nice to work with; and specially the way Apache's mod_php handles their workers (which is by far the most common deployment schema for PHP)
Disposability: If you use the right tools there is nothing inherent on PHP to prevent you from creating fast, disposable, tidy web and worker processes. However I believe that since the underlying process model is hard to implement as per points 7 and 8, then 9 becomes a bit cumbersome as a side effect
Dev/prod parity: This is very platform agnostic, and I would say one of the hardest to get done right. PHP is no exception to this rule, but it doesn't have a particular impediment either. Actually most of the tools named on the manifesto can be applied to a PHP project
Logs: Having your app agnostic of the log system on the execution environment is totally doable on PHP
Admin processes: The most important flaw of PHP regarding this point is its lack of a REPL shell. Regarding the rest, several frameworks like Symfony allow you to program admin tasks (e.g Doctine-based database migrations) and run them on the same environment as your "regular" web envionrment.
Since the PHP community is evolving, it may be that it has already righted some of the wrongs mentioned.
Build, release, Run: Applicable to compiled code which is not the case in PHP. So this
point is not something you need to look at.
I don't claim any authority on this 12 factor stuff, but my read of that section is that the author would disagree. It's not just about compiling, it's about managing dependencies both in the small (the snapshot of the code) and in the large (any libraries the code uses).
Imagine you're a new dev and they say, "Okay, this is a custom php app, so...
a) The custom code is really two subprojects, which are in repo A and repo B.
b) You'll need to create a directory layout like so, and then
c) check the code for each subproject out into this subdirectory and this subdirectory.
d) You'll also need these three open source PHP libraries:
version 3.1 of library Foo,
version 2.3 of library Bar, and
version 5.6 of library Bat.
e) download them from their home project sites and unpack them, then copy them into this directory, that directory, and the other directory.
f) then you'll need to set these configurations in the external library,
g) and these configs in our two custom code projects.
h) once that's all done, tar/gzip it all up, upload it up to the QA server and untar it into htdocs.
There's no compiling going in that set of steps, but you can bet there's a lot of building.
Getting all of that set up and working is the build step.
Using tar/gzip to take a snapshot of the working build is the release step.
SCP'ing/unpacking it into the QA server's htdocs directory is the runtime step.
You might say that some of those steps above are unnecessary - the libraries should be deployed at the system level and merely imported. From the 12factors.net site I'd say the author prefers you to import them uniquely and individually for the app. It sidesteps dependency versioning problems at the cost of more disk space (not that anybody cares). There are more hassles in managing all those dependencies as local-to-the-app, but then that's the point of the build/release/runtime scheme.
It might have changed since you read it - there are a few PHP examples now, although a few of them seem like negations of the twelve-factor concept.
One of the ways that normal mod_php sites violate twelve-factor comes with VII. Port binding. From the manifesto:
The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
However, apache/php can be coaxed into this worldview with something like this:
https://gist.github.com/1398498
Not perfect, but it works for the most part. To test it out, install foreman:
gem install foreman
then run it in the directory you cloned the gist into:
foreman start
then visit
http://localhost:5000/foo
DO NOT TAKE THIS POST AS A REFERENCE, THIS WAS WRITTEN IN 2011, MANY THINGS HAVE CHANGED SINCE THEN... THE WORLD OF PROGRAMMING IS IN CONSTANT EVOLUTION. A POINT OF VIEW OF 2011 IS NOT NECESSARILY STILL VALID IN 2018.
I just read a few lines of each points and here goes my analysis of the document:
Codebase: Everyone, php or not should have a codebase even for the little projects
Dependecies: PHP uses includes and code libraries that you should always be able to port easily by simply copying the code to a server. Sometimes you use PEAR and then if the server doesn't support it, you have to copy and install pear manually. I use Zend Framework most of the time, so it's just copying the code of the framework with the ftp upload.
Config: It is common for php apps to have a writable config file that you store configurations into. Where you store it is your choice as a developer, but it is usually either at the root of your app or in a settings/config folder.
Backing Services: PHP does use backing service most of the time such as MySQL. Other common services depending on your app are twitter and facebook. You use their API to communicate with them and store/retrieve data to work with.
Build, release, Run: Applicable to compiled code which is not the case in PHP. So this point is not something you need to look at.
Processes: HTTP is stateless and is SERVED,thus, you usually have no process apart from the web server. This is not entirely true as a webservice may be bundled with applications you package with or create for it. But, for the sake of standards, you usually don't have to use processes in the web world.
Port binding: PHP doesn't apply to port binding at all because it is not a process that hooks to an address, Apache, NGinx or Lighttpd does that for you. Reading #6/7 makes me understand that a website could never be a Twelve-Factor app.
Concurrency: Again this point treats about processes which do not apply to PHP web pages. This point applies to the server serving the content.
Disposability: This point discusses about how fast a process should be. Obviously, PHP web sites not being a process shouldnt apply but always note that your website should execute pages as fast as possible... Always think about this block or that block of code and see if it is optimized.
Dev/Prod Parity: This point is crucial in any app development. You never want to have a large gap between two app versions or upgrading can become a hassle. Furthermore, never create client specific versions of an app. Always find ways to allow your app to be configured/customized at the template level so you can keep your app as close as possible to all installed versions everywhere.
Logs: Logs are always a good thing to have, they allow you to follow the process of your code without having to output it to screen. My favorite tactic is to "tail -f logfile" inside of a linux console and look at what is happening as i execute my code.
Admin processes: Not applicable, in php, you don't have processes, but you do have pages that you can secure with usernames and passwords.
I've spent some time now developing a web application in php. It has mostly been just for the fun of learning as a side project, but the app now has a few users which I don't want to upset by breaking things as I develop.
At the moment, I have a very rudimentary method for managing the development - I use a text editor (ultraedit) to write the code and use its built in ftp to upload the files to the server. In terms of version control I have 2 domains, and only push files to the "live" domain when they work, but that's it. The domains are hosted on a cPanel shared hosting site which I have some doubts about its ability to handle even minor spikes in traffic. I looked at slicehost yesterday for something more scalable but that looks like a bit of a learning curve from where I am now.
I know I could do better than this, but where to start? I think I need advice on three things
1 - code writing tool
2 - version control / management
3 - scalable hosting
I've deliberately asked these in the same question as I'd like to know if one choice impacts another. Is there a good integrated solution?
Thanks in advance as ever.
Each part of your question has been answered before. The list below lists some of the common tools to use and links to appropriate searches on StackOverflow. There is no all in one package and going into details about these tools in one question is out of scope, so I am afraid you have to do some digging:
SVN, Git or Mercurial
UnitTesting (PHPUnit or SimpleTest)
Continuous Integration
Phing (for deployment)
phpqatools.org
Netbeans or Eclipse (for an IDE)
Disclaimer: list is not meant to be complete and order is not important
There is a lot going on here. I'll give you my two cents though.
I used to use ultra edit. Now I use netbeans, its a fully integrated development environment and it makes my life soooo much easier. Its free too. I can't imagine ever going back to UltraEdit. Also, which brings me to number two, netbeans has SVN and CVS integration
I would use subversion for version control. In my experience it does everything you need for version control. Others use ones like git and mercurial, but I think SVN is widely supported and easy enough to set up. As far as pushing code to the server, i've begun using svn for this too. I first ssh into the server and checkout the code into the public_html directory, and then set up an alias to do svn updates through the command line... its way easier than ftping in my opinion. There are other deployment methods, but i've never used them. see this question:
What is your preferred php deployment strategy?
obviously shared hosting is not going to handle traffic as well as a dedicated server. But there are lots of things you can do to improve performance before moving to a dedicated server. Check out this article: http://developer.yahoo.com/performance/rules.html
It seems that you're after a robust deployment strategy as opposed to a development one. But, correct me if I'm wrong.
In terms of 'code writing tool', and
IDE choice is a subjective
discussion. Feel free to work with
the one you are most comfortable
with, for me this is Netbeans.
As for a deployment strategy, I think it was best summed up in this answer.
Your point about scalable hosting is fairly broad. We will need much better forcasted metrics to give better advice. However, for now, if scalable hosting is a worry then maybe look into some sort of Cloud Hosting.
Have you looked at using wamp/xamp/mamp/lamp for development locally? Uploading via ftp for every change is a pain.
You could do that for local and see that everything works, then push it to your test domain and run through it again and then finally push live.
Might want to look at something like SpringLoops for doing your version control - this has the advantage of doing the deploy and then if it goes pear shaped you can revert it (free account gets 3 deploys a day).
I wouldn't worry about scaleable hosting just now, just focus on the site and the coding, you've only got a few users - wait till it starts becoming a problem before moving (however, I suggest looking into options) but don't try and get all cloud ready - might not ever be a problem.
ps, go with Linode over Slicehost.
I think use Aptana Studio ( http://www.aptana.org ). It is an Eclipse based IDE with all the tools you need integrated in it. It has integrated PHP development tools, GIT or SVN for version control.
I've used shared hosting as well. Once an other site on the same server had DoS atacks and my site became unreachable as well. Otherwise it could work in reasonable speed after some optimization. It served 1000-3000 users per day.
Dedicated servers are much better. Or you can use Amazon web services. I know they are more expensive.
1 - code writing tool
Zend Studio. I would recommend Linux as well if you are going to use linux servers.
2 - version control / management
SVN + phing (if you are going to build serious applications).
3 - scalable hosting
Amazon or RackSpace.
For your editor, just use what you are comfortable and productive with. You most definitely should have version control in place. You never know when you need to rollback a version or two.
I always keep at least 3 versions on the production server. I use symlinks to point the web server at the latest version. If there is a problem, you just need to recreate the symlink to point to an older version.
As for shared hosting, you'd be surprised out how much bandwidth you can get. I have a $10/month shared host that gets about 500K page views a month. Generally, it's not that your shared host can't handle the load, it's that the hosting provider puts too many "shares" on the same server. So it depends on how much resources everyone else on the same server is using. If you are having issues, you can always ask to be moved to a different server.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I have been hearing a lot about the advantages of using a version control system and would like to try one. I was doing freelance web development in PHP for the past 2 years, two months back I hired two more programmer to help me. I will be hiring one more person soon. We maintain 4 websites, all of which are my own, which are continuously being edited by one of us. I learned PHP by myself and have never worked in any other firms. Hence I am new to version control, unit testing and all.
Currently, we have development servers on our workstations. When we edit a particular section of a site, we download the code for that particular section (say /news/ or /movies/ or /wallpapers/ ) from the production server to the dev server, makes the changes locally and uploads to the production server (no code review / testing). Because of this, our dev server is always out of date from our prod server. Occasionally, this also create problem when one of us forgets to download the latest copy from prod and overwrites the last change. I know this is very very foolish, but currently our prod server is the only copy that has all the updates and latest changes.
Can anyone please suggest which is the best version control system for me? I am more interested in distributed version control, since we don't have a central backup for all our code. I read about Mercurial and Git and found that Mercurial is used in several large open source projects by Mozilla, Sun, Symbian etc. So which one do you think is better for me? Not only version control, if there are any other package that I can use to make my current setup better, please mention that too :)
It sounds like Git can accomplish your goals quite well. As it's distributed, it's excellent for working locally since you can perform most operations (commit, revert, diff, patch) without connecting to a central server. You can also avoid that ugly moment of someone pushing new code to production while someone else is working on it, and then having the complicated task of merging those two versions of the code together (git provides a useful tool for doing this called rebase).
You noted there's some big projects using Hg (Mercurial), but there's some pretty big ones using Git, like the Linux Kernel, X.org, Android and Debian.
I use git for all my sites: it's lightning fast, efficient, and easy to use.
Edit: If you want to get into using Git, I'd recommend doing some reading before jumping right in. Starting off on the wrong foot can have some terrible implications later on. If you follow an Agile Workflow, you might want to check this out. Here's a website I learned most of my Git know-how from.
Version control is an incredible tool even when you're working alone, and when you are working with someone else it's indispensable. I would recommend using git. It's very fast, has a really great set of available tools, and of course has github.com. Mercurial is basically just as good as git, but it runs a little slower and doesn't have github.
For why to use git, please read http://whygitisbetterthanx.com/
Here's a nice-looking tutorial on getting started with git: http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html
You can use SVN, Git, Mercurial.
The biggest challenge is having everyone be disciplined in using version control and not getting lazy.
Definitely Mercurial. Although you can use either Git or SVN, Mercurial is better for two reasons:
Vs Git: Good integration with Windows.
Vs SVN: It's distributed.
If you don't want to run yourself a Mercurial server (which is pretty easy anyway), there are many services available. Kiln + FogBugz is an EXCELLENT combination. There's also CodeBaseHQ (also supports Git and SVN), Bitbucket, and many more.
Before you jump onto it I strongly recommend you read at least Joel Spolsky's tutorial, but I strongly recommend you also read Mercurial: The Definitive Guide.
I am sorry, I had no intention of starting a DVCS holy war. I am going to try Git.
Yes, version control will help. To get started, I see two important issues for you:
hosted or self-managed? Do you want to host this yourself on a server, or want a service to take care of it for you? There are reasons to go either way, but if you're not that into managing the server look for a hosted option.
SVN or Git There are others, but these are the top open source contenders.
Pros and Cons (my opinion):
SVN: Good tutorials and fairly easy to get up-to-speed with. The training requirement is small (I've done a bit of it). SVN works really well with a co-located team, lots of projects, etc. With a limited number of branches (you may not need any), it is solid. There are plenty of integrations with other tools.
Git: Getting started can be a little rougher than with SVN. Some of the docs are good, but lots are geared assume a rather thorough understanding of the internals. Once you get the hang of it, it has great flexibility, but I've seen almost everyone who has started with it really stumble when beginning. Even after working with it for months, people debate the best patterns to use. It's really sweet for 1-person projects (where you want to track history), and for distributed projects like GitHub. I use Git even for small co-located teams, because I enjoy the speed and flexibility.
Given what you say about your team, though, I'd probably recommend trying SVN. There will be better resources to help you get going, and you'll be less likely to get frustrated with it.
Hope this helps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm using PHPUnderControl which runs on top of Cruise Control for my continuous integration and unit testing. I also have it setup to run PHPDocumentor to generate phpdoc's for me and it runs PHP Code Sniffer to enforce coding standards for me. But now I want to set up something on that same server (Ubuntu) to make deploying to a remote server easier. I already have it setup so after every successful build an SVN Export is done from trunk into a directory within the projects folder on the server.
I've been thinking of writing a little custom PHP script that will SSH to a configured remote server, tarball up the latest export, copy it over, untar and run any migrations. A PHP script like this shouldn't be too hard initially, unless I need to eventually begin scaling to multiple servers. I know there are systems out there like Phing, Fabric and others.
My question is if anyone has any experience with these and can provide some pro's and con's? I've begun setting up Phing on my server and will be trying Fabric next to play with them, but was wondering if anyone who has used them more extensively, or had to scale them, could provide some feedback.
I've used Capistrano with PHP (even though it's more of a Rails-y thing as it's written in Ruby).
It's been really straightforward to use, but that said I haven't had to scale much with it. We do deploy to various different staging/production servers though, and the multi-stage extension has been useful in those scenarios.
However like most things Ruby, there's a lot of hooks and "magic" which can get confusing if you're new to Capistrano and trying to do something tricky with it.
As for how it compares to other deployment tools, I can't comment. I know we used to use Phing, but I'm uncertain why we switched to Capistrano.
If you like Capistrano, but wished it was a bit more PHP'ish, check out Fredistrano.
I wrote an automated build (SVN export, Zend Guard encoding, etc) and deployment system using Phing once and found quite the pain to use. Whenever I had to write a special task I felt I had to jump through way to many hoops just to get it to work.
So, these days I just write simple bash scripts that does building with SVN checkout, encoding, creating a tag in SVN and deployment through rsync. It may be low-tech, and Phing may have some superior features, but atleast it doesn't get in my way.
Theres a new build tool, called Bldr. It uses Yaml for config, instead of xml like most of the build systems out there, and its highly extensible.
http://bldr.io
We use phing and it has come in handy. We don't use it for packaging, but it shouldn't be too hard to make it do what you are looking for. We mainly use it for common tasks such as clearing caches, building development sites, and other tasks to aide in development. Its been a big help, and from what I can gather it seems to be an ant clone, although it might not have all the functionality that ant has.
If I was to implement such a deployment system, I would probably opt for a slightly different solution from what you've outlined above. Instead of having code that runs locally on my system, connects to a list of remote servers and does the "work" there, I would pack the updater module with the rest of the code and have it pull the update data from my server on demand (or rather when I "told" it to do so). That way you have much less to worry about on your end (you just need to serve the updated code via http when requested, and the remote server handles the rest). Just my 2 cents.
I've written my own rsync like tool for this because i work from a very bad internet connection in a 3rd world contry and have all kinds of failures and starving connections so that rsync does not work.
On your remote system you should at least write a litte script that is doing backups before running migrations.
Better is you are using a total independent mirror system on your web host system and include some small but fundamental unit tests after a migration. Then do a root switching to put the updated website online. This would require to run a few interactive services in read-only mode during migration (unfortunately a feature that not many people implement).
But first of all - think if it is really worth your time doing this - if you only update each a quarter then a simple checklist on paper would be enough.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have absolutely no idea about version control. Only that it can be very useful in many ways.
I have found a few related questions but none that start from the absolute beginning.
I am the only developer at my work using Mac OS X and traditionally just been using FTP.
Can anyone help me with version control in relation to PHP projects (does it matter)?
Yes, try it out, it's worth it. And the language you are using doesn't matter. It's working great with PHP for me and it will for you too.
Benefits
If you are the only developer, it is indeed easier to go without version control. However, you will find great benefits to using a version control system. Some of the easiest benefits will be:
Never wondering what is your latest version once you go back to a project (no more myproject090201-archive2-final6.zip)
Never fear to start off some major refactoring, if you make a mistake on your file, you'll just rollback to the latest version
If something stops working in your project and you have the feeling it worked at one point, you can test some of the prior versions easily and look at the difference between the working version and the non-working version to find what broke the code
Additional backup of your current project, and even better if it's not on your machine... of course, additional points for backing up your version control system, we're never too cautious, you don't want to have to restart that month-long project do you?
Choices
As some have said, you have a few choices for your version control system and I guess you'll want a free one to begin. There are a few excellent commercial products but the free ones have nothing to be ashamed of. So here are some very popular free version control systems:
Subversion (also called SVN)
Git
Mercurial
Bazaar
Centralized versus distributed
Subversion has been there for a while and it's one classified as 'centralized'. Meaning everyone will always go fetch the latest version and commit their latest work to one central system, often on another system although it can easily be on your own machine. It's a process easy to understand.
The three others are called 'distributed'. There's a lot of different possible processes as it's a more flexible system and that's why those three newcomers are getting a lot of traction these days in open source projects where a lot of people are interacting with one another. Basically you are working with your own revisions on your own machine, making as many copies as you need and deciding which versions you share with other people on other computers.
The trend definitely seems go towards distributed system but as those systems are more recent, they are still missing the GUI tools that makes it really user friendly to use and you might sometimes find the documentation to be a bit lighter. On the other hand, this all seems to be getting corrected quickly.
In your case, as you are working alone, it probably won't make a big difference, and although you'll hear very good points for centralized and distributed systems, you'll be able to work with one or the other without any problems.
Tools
If you absolutely need a GUI tool for your Mac, I'd then choose SVN to get initiated to source control. There are two very good products for that (commercial):
Versions
Cornerstone
And a few other ones (such as the free svnX) that are becoming a little bit old and unfriendly in my opinion but that might be interesting trying anyway.
If you don't mind not using the GUI tools, with the help of Terminal you'll be able to do all the same things with a few simple command lines with any of the aforementioned systems.
Starting points
In any cases, you'll want some starting points.
For Subversion, your first stop must be their free book, Version Control with Subversion. Take a few hours of your day to go through the chapters, it'll be time well invested. The introduction chapters are a good read even you don't want to use Subversion specifically because it'll get you to understand version control a little bit better.
For a distributed system, I've had fun with Mercurial but it's an easily flammable subject so I'll let you make your own choice there. But if you end up looking at Mercurial, have a look at this blog post, it was an excellent starter for me that'll get you up and running with the basics in a few minutes if you're already a bit accustomed to version control in general. Anyway, drop by Mercurial's homepage and have a look at the Getting Started section of the page.
Conclusion
Give it a go, invest a day trying it out with a few bogus files. Try out renaming files and directory, erasing, moving things around, committing binary files versus text files, resolving conflicts and reverting to older versions to get a hang of it. These are often the first few hurdles you'll encounter when playing with version control and it'll be painless if it's on a non-production project.
In any cases, it's something well-worth learning that'll be helpful with your solo projects as well as if you end up working with other developers at your current job or your next one.
Good luck!
The type of code is irrelevant.
One open-source and popular version control system is Subversion and there is a very good overview/manual here.
I use Git for PHP development.
It's fast, flexible, reliable, clean (CVS and SVN create a lot of hidden folders that I personally don't like).
Its distributed nature allow to work the way you want (with or without a central repository).
You can find more about it here:
Gitmagic
Speed Benchmarks
Moreover, you can get the Eclipse PDT (PHP Plugin) and use Subclibse in the IDE.
Versions is working well for another developer I work with. Additionally, if you are using Textmate the SVN bundle provides pretty much all you need for most parts of the Subversion workflow. I really like it.
The Project Plus plugin takes it a step further by adding small unobtrusive badges to versioned files in the project tree, showing at a glance the state of files in a project.
If you're on a Mac, do yourself a favor and pick up Versions, a beautifully designed (and highly functional) Subversion GUI. You'd do best to learn the terminology and get an idea of how Subversion works using a GUI before you jump to the command line. Once you're able to commit revisions of your code and run updates to get other people's work, then go back and read the red bean book (it really is the best way to learn Subversion in-and-out).
http://versionsapp.com/
use bazaar http://bazaar-vcs.org/
it's very nice and you can start using it in minutes.
Check out other options too - Miscrosoft's TFS (this not only used for source control system but for defect tracking, project management etc etc) , Bazaar, Git are popular ones.
Alex,
Version control (and some will scathe me for this statement) is not a trivial matter, and even very experienced developers get themselves into trouble. The most frequent causes for frustration are limitations of a particular product (Visual Source Safe is a famous one), and members of a team not following the same process, or not understanding the process at all.
This should not stop you from looking into using a source control tool - the opposite is the case. You can only use a tool effectively if you understand what it does and why.
I would recommend that you look into CVS. It has been around for many years, it is relatively simple to install, set up, and use, and while there are GUI clients available for most platforms, learning it from the command line may provide the best access to its features.