Collaborating via SVN
Dragan on 17. Feb '08 4
Anyone who has ever worked in a team before knows how important good collaboration is. People need to “click” when they are working in a team. And also, anyone who has ever worked in a team – and works with code – knows how important synchronization and versioning is.
Subversion – It’s Not Just For Programmers You Know
I for one got into the whole thing a little bit late. Me being a designer and all, I was kind of hesitant to jump into the scary world of command lines and installing software that doesn’t have “point and click” install procedures. Turned out it’s not like that at all! – there is no need to install anything yourself (besides the optional SVN client) and Terminal isn’t that scary at all.
Even though I am a designer – I work with code a lot. At Superawesome we do a lot of xHTML/CSS work. Before the way our workflow was like this:
- slice up the images
- write the markup and hook it all together through CSS
- upload to our staging server so it’s available to other people
- worry about who did the last revision
- send it away to programmers hoping everything works the way it should
I think I don’t need to explain to you how cumbersome this soon becomes – now think multiple projects.
Oh, Hai SVN – Make My Head Hurt Less? Kthanxbai.
We are fortunate enough that we are living and working in a day and age where we don’t have to really know how to run and operate every single thing we need to use. I couldn’t install SVN on our server to save my life, but thanks to a wonderful service such as Beanstalk our SVN repos were up and running in a matter of minutes. Each active project has it’s repository and we’re committing our way to worry-free weekends.
Bean Stalk – There’s More
With serious concern of this being turned into a full blown Beanstalk promo, I can’t help but make one more reference to their great service – I just love it when things work well and deliver things you didn’t even expect.
Beanstalk showing differences (red – old, green new) between two files after commit.
Seeing how every commit is followed by some descriptive commentary (at least it’s considered good practice), Beanstalk makes a page for each and every commit with that message, and it shows the differentiation between the new and the old versions of the documents changed in the commit. And all that is packaged in a really sweet interface showing the changes line for line with clear differentiation.
So if you aren’t using subversion please take my advice as an ex non-believer. It has made a serious positive change in my work and I am sure it will do the same thing for you.
Good for you that you are discovering the benefits of version control.
Now that you are familiar with the checkout, update, commit cycle, I’d like to point your attention to a slightly different but IMHO better version control. Its name is ‘git’ (just as SVN’s name is ‘svn’).
Git offers the same comforts of version control, except that it does not need a central server to store everything on. Also, it has ‘traditional’ branching and tagging management, which SVN broke away from to the dismay of many.
This is what people call ‘distributed version control’. Contrary to svn, which is ‘centralized’ version control.
Why is distributed version control good? In svn, you can not have version control if you don’t see your server via the Internet. For instance, if you are on a plane, and want to commit edits to your code, you will have to wait until it lands and you can reconnect. If you want to send edits to your colleague, you have to wait to reconnect. Even if your colleague is sitting next to you in the airplane. And that sucks.
With git you can simply mail your changes, and be done with it… at least that’s what I do. I also have a mailer daemon that automatically sorts the mail once connection is up. But my part of the work ended when I clicked ‘send’, which was at some 10km above ground.
Or the colleague and I can exchange patches on USB drives or something. (and these are still fully version-controlled!)
Git isn’t the only distributed version control program out there. IMHO it has the right balance of do’s and dont’s. Give it a try, you will not be disappointed. The link to it you can find yourself. Google is your friend.
— filmil 21. February 2008, 04:48 #
thought this was a post about Signal vs Noise. not a programmer, so i have no interest in subversion, but i like the design of your site so I’ll stick around.
— Scott 12. March 2008, 12:23 #
Can you explain the repository concept to me? If I create a new file, Do I want to do a certain amount of work before importing it to the repository. Isn’t it double work to create a file, move it to a repository and then check out a working copy? What do you do with the original copy once you imported it to the repository and check out a working copy?
— Shawn Stringfield 14. December 2008, 03:32 #
Shawn, SVN works in the way that it monitors the files on your computer (called a “working copy”) and compares them to the ones in the “repository”. When you add a new file to your working copy you must also add it to the repository, otherwise SVN will ignore it. GUI clients will let you do this in bulk or with a click of an icon/button, otherwise you have to add it manually via the command:
Once you add the file, it is monitored by SVN and it’s changes are recorded in your revisions.
— Dragan Babić 15. December 2008, 21:06 #