Search code examples
svncoda

Subversion demystified?

I finally decided to move towards a version control workflow but...it's a month I'm trying to setup a workflow with SVN with no luck.

I work with Coda (svn is supported) + Media temple hosting. I just set-up a repo (following MT guide) in /data/svn/myproject and imported my website root.

Problem 1: svn imported only half of the files in the root and not the directories.

Then I tried (following a tutorial) to checkout in Coda.

Problem 2: I get an error (local dir is not a working copy) and only a .svn folder was created.

Now, I'm thinking I've not understand at all how a versioning system works. Just make clear to me: when I checkout files for first time they will be copied from my remote dir to my local folder? FTP and version check remains two separated tasks? I mean: when I commit a file in Coda, will it be automatically put on my remote website directory updating the old one? And, it's only about code or everything is put under version control (images, etc....)?

Sorry I've read a lot of guides before asking, but I don't get it!

Thanks

Solution

  • First of all, I'd advise you to think of the version control as a separate thing from your IDE. It works at the filesystem level anyway, and whatever integration Coda offers you is only an abstraction to that. Initially it will be easier to understand things if you take Coda out of the equation.

    Now, I personally dislike the command line (though it is powerful, of course) so if you were on Windows I'd advise you to get Tortoise and play around with that, it would give you a better feel for things. On Mac though I don't know. Perhaps there is some nice graphical tool for SVN on Mac as well.

    Basically, an SVN workflow consists of two things - the Repository, and your local folder. The Repository is like a server. It's the central location for all things. Think of it like a "smart FTP folder".

    The workflow is like this: you write all your source code and stuff in your local folder. When you feel that you are done, you copy it to the central folder (repository), and start working on the next thing. When you are done with that, copy it to the central folder again. And so on. This action is the "Commit". You copy your local files to the central folder, overwriting whatever was there.

    Well, it's actually a bit more "smart" than just simple copying. SVN tracks all changes, so when you delete a file locally, the commit will also delete the file on the server. It's like making the server folder look exactly like your local folder.

    Now, the main selling point of a version control is that all these updates of the repository are non-destructive. That is, when you copy your latest greatest stuff to the repository, it archives the old files that were there and you can get them back at any time. It's actually quite difficult to really delete something from an SVN repository. That's why even single developers tend to prefer using a source control - it's like a backup system, if you mess up, you can always take the old version and start over. Nothing is lost. And it's done pretty efficiently too.

    The other main advantage of SVN over a simple FTP folder is when multiple users are doing changes to the same files. It keeps track of things, so when you and your buddy have both modified the same file, it will warn you upon committing. Most often SVN will be able to merge your changes automatically, but sometimes you will have to sort things out by hand too. But again - nobody can accidentally lose their changes because someone overwrote the file they modified. The history keeps it all, and as soon as you both try to overwrite the same file, you get big fat warnings and stuff.

    So, the workflow...

    Well, most of the time it's like this:

    1. You set up your repository. It's empty initially, like an empty folder.
    2. Then you "check out" the empty folder to your local folder somewhere. Pick a fresh empty folder as well, just to be safe. This is kinda pointless, but it establishes a link between your local folder and the repository. Namely, the little .svn folder will be created (you should leave these little folders alone and ignore them). From now on, SVN will know that this local folder mirrors the repository folder, and will commit to that repository folder.
    3. Now you copy all your stuff in the new empty folder.
    4. Say to SVN "Add all files". This will mark all files as new additions that should be copied to the repository the next time you commit. Now, normally there will be some files that you won't want to copy to the server. What you include there and what you don't is up to you, but typically all things that pertain to the program source (including resources like images 'n stuff) are copied, while local files auto-re-generated by the IDE are left out. Think of it this way - when another guy would want to join you, he would take all the files from the repository. Which ones would be relevant for him, and which ones would he delete? SVN also includes a feature called "ignore" so that it doesn't prompt you about unnecessary files in the future.
    5. Then commit. This will copy your files to the server and populate the folder there.
    6. After that, start working on the next feature. When you are done, commit. And start on the next feature. Etc. Actually, you should commit whenever you feel like it. A rule of a thumb is - keep the server copy in a sane state. Don't commit if it doesn't compile, or is in the middle of some messy rewrite which leaves half the program non-working. Commit completed things.

    That's pretty much it. If you are working together with your buddy, you'll also do an "Update" every now and then. This will copy the changes your buddy has committed to your local folder.

    There are other useful features of SVN, but this is the basic setup. Get comfortable with this, and then look for more.