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.