Becoming familiar with Subversion
I have finally taken the time to learn a little bit about Subversion – it is now a part of my development process. I’m getting into the habit of committing frequently—it’s the first thing I think of once I make decent progress. I don’t know what’s considered “frequent,” but I usually commit around 10 times a day. It’s easier to add meaningful comments when you commit often. It’s very comforting knowing I have a solid, working backup of what I’ve done so far. It’s like save points in a game, only for programming. At work we had to deal with a couple of conflicts, but Subversion handles them very well. The split display of the repository file and your local file works out nicely. Especially considering how it lets you copy the current change into your file and vice-versa. I don’t know if I’m doing this the most efficient way, but if a conflict does arise, here are the steps I take:
- Compare with repository
- Navigate through all changes, accepting the ones I want
- Save the changes and mark the conflict as resolved
- Update my files (because it still doesn’t let me commit right away)
- Commit my changes
It’s a fairly simple process. Before, I was forced to use SourceSafe (at work) which had mandatory file locking, so I was skeptical as to how it would be without it. But Chris was right, it does seem to be a rare occurrence that two people are working in the same methods at the same time. The only reason it does happen to us is because we have a guy working on the same project about 40 miles away, and we aren’t always on track with one another. But I think we have that straightened out now.
Another thing I find to be really, really impressive is migrations. It’s amazingly easy to keep up with database changes throughout the life of a project. The migration files are incredibly easy to write, but even better yet, getting the changes someone else has made is even easier. Two commands: svn update and rake migrate. That’s it. At this point, I can’t think of (nor do I know of) any other way that is more convenient than that. Rails generates the SQL code for you, so I’m assuming you can use your migration files on any type of database you want (MySQL, SQLServer, Oracle, etc.) to completely generate (and keep-up with) your schema. It just amazes me.
Chris Monday, 11 Sep, 2006 Posted at 05:54PM
Even better, when you use SQLite3 as your development database, you can create branches in svn and completely alter the db structure. That’s pretty handy when you are trying out the addition of a new ActiveRecord model, or renaming a bunch of fields in an existing table.
Ryan Thursday, 14 Sep, 2006 Posted at 04:08AM
I haven’t got into branches in svn yet. What’s the main idea behind a branch? Is it another copy of something? And how do tags come into play in svn? I’m guessing it’s not the type of tag I’m thinking of?
Chris Thursday, 14 Sep, 2006 Posted at 06:05AM
Branches and tags are really the same thing: cheap copies. A cheap copy is initially created using ‘svn copy’ and it’s “cheap” because it doesn’t actually copy any files – it essentially creates a new history for the file at the point of the copy. So, when you branch, you are saying “from this point on, I’ll have at least two separate histories for these files.” Later, though, you can merge them back into the trunk.
Tags work exactly the same way as branches. However, the general idea is that tags are “read-only” (although this isn’t enforced at all by subversion). Essentially, tags are a way to give a name to a revision.
Normally, you create a branch when you are prepping for a release, and then tag the branch when you officially release. You can also use tags for bug fixes (tagging the code with pre-ticket# and post-ticket#) and then create diff patches that can be distributed to customers. That’s the general idea.