The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Subversion Best Practices

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Jared Richardson

Posts: 1031
Nickname: jaredr
Registered: Jun, 2005

Jared Richardson is an author, speaker, and consultant who enjoys working with Ruby and Rails.
Subversion Best Practices Posted: Aug 22, 2006 8:32 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by Jared Richardson.
Original Post: Subversion Best Practices
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog. The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
Latest Agile Buzz Posts
Latest Agile Buzz Posts by Jared Richardson
Latest Posts From Jared's Weblog

Advertisement

I'm one of the many who've used CVS for years and have switched to Subversion. Initially I used Subversion naively, treating it like CVS. However, as I use it more, I'm learning my way around.

Subversion was designed to make CVS users feel right at home. All the basic command syntax was reproduced. The biggest difference I've seen is the way that you setup your directory structure in Subversion.

In CVS, I would just add
/projects/my_first_project

and later
/projects/my_second_project

and so on. When I needed to tag or branch, I would apply the tag to the files. It's a concept that long time CVS users know very well.

Subversion handles branches, tags, and releases very differently. It has you make a copy of the tree, but the copy is just pointers to the existing files. It's not a physical copy. If you have a two gig file and you execute "svn copy svn://my_server/big_file_one svn://my_server/big_file_two", you won't have a four gig repository. You'll have a two gig file and a pointer to that file in the copied location.

Once you get this concept, then you understand why Subversion repositories are set up a little different than a CVS repository.

/product/my_first_project/trunk
/product/my_first_project/releases
/product/my_first_project/branches

All the code goes into the trunk directory. When you need to tag a release or a branch, you copy the project into releases/my_1_00_release. If someone needs to work on that release, they check it out. Or they use the "svn switch" command to point their local code to that copy. I've even see an example or two of
/prodcut/my_first_project/branches/personal/

This lets everyone on the team branch out as often as they'd like to experiement.

At first this change didn't set well with me, but I like it quite a bit now. Tags and branches in CVS aren't mysterious, but they aren't obvious either. The tags are metadata and you have to go looking for that information. In Subversion, that information is a part of the directory tree as well as metadata. I think the Subversion way would be much better for a new user, especially one unfamiliar with the concepts.

Jared

Read: Subversion Best Practices

Topic: RIAA stunned by the obvious Previous Topic   Next Topic Topic: Lipstick on a pig

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use