Home › Forums › Technical › Banner INB (technical)

Using Subversion for Version Control

Thu, 2007-09-20 13:33 — kstens

Hi,

We are planning on starting to use SVN for version control. We already have many modifications to baseline Banner, but have done version control by making and modifying local copies and then moving them back to to the server and manually creating backups of previous versions. Our team does not have much experience with using version control software, so we're hoping to get some suggestions.

What are some of the issues with SVN that have made it difficult to use for Banner development? What were some workarounds for them? Would you use it again? Is there any other version control software you would recommend instead?

Does anyone have any general advice for starting to use SVN for Banner modifications? This is a pretty broad question, but any advice for best practices for using the software day to day, and for setting up the repository would be appreciated.

There was a recent post about tracking modifications that suggested a structure for the repository. Specifially, having a separate vendor trunk that contains only SunGard's source and using that to merge their releases with a trunk that contains all custom the modifications. Any new modifications are then created as branches on the trunk, and then merged back to it when they are complete. Does this sound like a good way to structure things to anyone else? Does anyone else do it differently?

Thanks,

Kirk

‹ Using the AddStudentAccountTransaction API I have a form interface problem ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Tue, 2007-09-25 11:53 — jhord

Re: Using Subversion for Version Control

Our decision to use a vendor trunk was based on recommendations from the subversion book (http://svnbook.red-bean.com/). We altered the directory structure somewhat, but the overall idea is the same. Instead of having a fairly flat structure to the vendor branch, we went ahead and created a standard repository structure (with branches, tags and trunk directories) beneath a vendor directory in the repository root. This just keeps things a bit more organized.

In general, your local modifications will need to merge with SunGardHE's changes as upgrades and patches are applied to the system over time. Having a vendor branch allows you to offload some of this work to subversion instead of doing it by hand. As an example, let's say you have made modifications to a file at version X and now you need to apply a patch to get you to version Y. If you knew what SunGardHE had changed in that file between versions X and Y, you could apply those same changes to your locally modified version, thereby updating your version of the file to version Y while maintaining your customizations. That's exactly how you approach the issue using a vendor branch in subversion.

Of course, this won't always work perfectly. When SunGardHE modifies a portion of the code that you have also modified, you will get a conflict. Subversion won't know which changes you want to keep and will mark the file in a conflicted state. At this point you will have to merge the changes by hand and then tell subversion that you have resolved the conflict. In practice this hasn't been a big issue for us, though. As an example, when we upgraded from Banner 6 to Banner 7, we had about 30 - 35% of the files in repository go to a conflict state, but only a few of them required more than a few minutes of time to resolve. It's certainly not perfect, but having subversion do 70% of the merging for us saved quite a bit of time.