Starting up Version Control

Background

After we finally decommissioned our old employee records system, it took a while to get the team up and running on subversion (svn).  I think its clear that source control is very important for any development process, but I get the feeling there are a lot of Oracle developers out there who aren’t using it. I can tell you this:  Leading the charge on my team’s move from manually managed (and occasionally forgotten) snapshots to svn has been one of the most rewarding experiences I’ve had since joining the team.

We chose SVN because

1. Our internal sys-admins were already comfortable with its installation and maintenance
2. I had prior experience from other projects (PHP, Java)
3. The feeling that DVCS (Distributed Version Control Systems) like git or mercurial were pretty big hammers for our small team (though I would like to put some time into learning one at some point)

Make an “Expert” / Choose Your Weapon

If you’re thinking of taking the plunge, I’d definitely recommend having one person lead the effort.  They can invest a few days tinkering with the tools, and getting a feel for what’s possible (commits, reverts, branches, merges, blames).  It’s hard to really lose things in svn, so it’s good to try some sweeping changes and re-assure yourself that you’ve got a proverbial net.  Once your “expert” trusts the tools and has some foundation, they’ll become the goto contact for the rest of the team.

Then as a team work with your expert to find practices that work for you.  We’re a Windows shop, so we’re using Tortoise SVN for its shell integration.  There are lots of tools out there, including command line clients, but we’ve really valued the immediate feedback that a change has been made and not committed.

Tortoise SVN’s Shell Integration on Windows

 Our Best Practices

We resolved to use the trunk as the authoritative resource — “if it’s in the trunk, it’s in production” became our mantra.  This allows us to easily branch and merge for each formal change request received through our ticketing system.  So each feature request becomes a branch.  Once the changes are approved merging the branch back to the trunk highlights what needs to be moved forward into production, and validates that we haven’t missed anything.

Probably the most important thing for proper version control is avoiding false positives.  You want to be sure that only semantic changes are brought to your attention while committing and merging.  So decide as a team up front how you feel about code formatting (trailing slashes, spaces vs. tabs, keyword case, block alignment, etc) and file naming conventions.  Our environment is a bit odd, in that we have one application spread across 3 schemas.  The reason for that precedes my joining the team, and is on our list of things it would be great to fix.  So, our convention is SCHEMA.OBJECT_NAME.type, then we sort the objects by type into directories.

We decided to use tabs instead of spaces, and avoid the trailing slash.  We also allow for formatting only commits, so if I’m working on a module that hasn’t been touched in some time and everything’s lined up with spaces, I can reformat it and commit with a message like “Cleaning up formatting before getting to work on ticket #XXXX”.  That way if someone else is reviewing changes, they can quickly determine that there shouldn’t be any semantic changes to the code, and skim through it to verify that.

Our Initial DDL Export

To avoid false positives, we had to do our best to use consistent settings for DDL export, and establish a rule that all development starts with a file in the repository.  This ensures that all changes recorded in the repository are actual code changes, and not artefacts of inconsistent export settings.  By using an automated bulk DDL export (in our case via Toad) we were able to ensure that all objects started out in the same state for naming and basic formatting (trailing slashes), establishing a common starting point to address spaces -> tabs conversions as those modules require revision.

We then used a small batch script to move files by type into subdirectories

placeExports.bat:

move *.pkb Packages
move *.pks Packages
move *.fnc Functions
move *.vw Views
move *.trg Triggers
move *.jvs Jav

Then we were ready to perform our first commit!  Over the next several weeks we re-exported a handful of times, as a self check — have we captured all the changes we made?

Resources

I’m not planning on getting into the specifics of actual branching and merging with svn, in fact these guidelines should serve you well to get started with any version control system and Oracle code.  But if you’re just getting started I can recommend some references.

• Creating a Branch with Tortoise SVN
• Merging with Tortoise SVN

Forward From Here