Version Control / Change Management - what do you use?

[Bishop]

Aside from Microsoft's Visual Sourcesafe, is anyone using any tools that allow for version control of source code while doing proper change management for Visual Basic?

By "proper", I mean in a large project(s) environment, where changes to multiple files can be grouped under a single "changeset". For the most part, my organization does this manually with Visual Sourcesafe, however we're growing and proper change management software may solve some of our problems.

[Hack]

I work for a commerical software development company and we have developers all over North America and in India. We use VSS on a global basis and as far as I know, it works just fine.

We do have a dedicated source control team that maintains VSS servers. Maybe thats the difference.

[szlamany]

Back when I worked for a larger firm, we had a team of librarians and source control people that were in charge of the SOURCE SAFE aspects and the "release" of modifications aspect.

Now, having my own business, with just a handful of programmers, this falls to me to handle. The hardest part is coordinating the changes to "control tables" in SQL with the release of STORED PROCEDURES and the release of the VB application.

We have developed several little utilities to assist in this. Move files modified since "some date" - create BAT files automatically that will OSQL the STORED PROCEDURES into the customer DB's. Utilities to create TEXT FILES of DB Control tables - and extensive use of WINDIF to compare archive folders of these text files.

[ducky]

I previously used VSS for the work done in our department, but now my company has chosen to use an enterprise solution by Serena. So now I've recently migrated to using Serena ChangeMan DS. It does "changeset" as you called it. Besides version control and change management, it can be used for distribution as well. Take a look at http://www.serena.com/

[Bishop]

Thank you for your reply. I'm starting to look at the website now, but I have a question for you about this software and Visual Basic 6 code.

Are you checking VB6 code in? If so, how does it handle the concept of merging code from branch to branch? For us, this is a major issue since VB6 code consists of a textual and a binary file (e.g. .frm/.frx files). I can't get my mind wrapped around how any product can solve the binary merging problem.

[ducky]

Yes we use it for VB6 code, sql code, documentation, anything really we want to track, binary or not. It can do merging, but we do not use it since in our situation we only allow single user checkouts, and do not allow merges. I'm sure the .frx and other binary merge is a problem with any version control system, or do you have an existing system that can do this to the .frx files?

[techgnome]

Back when I worked for a larger firm, we had a team of librarians and source control people that were in charge of the SOURCE SAFE aspects and the "release" of modifications aspect.

Now, having my own business, with just a handful of programmers, this falls to me to handle. The hardest part is coordinating the changes to "control tables" in SQL with the release of STORED PROCEDURES and the release of the VB application.

We have developed several little utilities to assist in this. Move files modified since "some date" - create BAT files automatically that will OSQL the STORED PROCEDURES into the customer DB's. Utilities to create TEXT FILES of DB Control tables - and extensive use of WINDIF to compare archive folders of these text files.

Holey crap batman! For cordinating db changes we oddly enough leverage the ability of VSS lableing. Our VSS structure is such that each part of the system is it's own project with it's own VSS folder. Under each VSS folder, there is a Stored Procedures and Tables folders. I'll let you guess what goes in each. Now, each SP and table is then shared to a common SP and Tables in the main root of the app folder in VSS. It then works like this, if I make a change to a project and need an SP that does XYZ, I look in the common SP folder for one that already does XYZ. If I find it, I simply then share it to the project that I need it in. If I then need to check it out to make a change, I do that under the project. When done, I label it with the issue number that caused me to change it.

We then build an app that allows us to create builds based on client & issue numbers... it then will loop through all projects in the build and gets the assigned version (based on the issue #). As part of the get process, it gets the SP and Table folders along with it. Then through some voodoo majic that I don't quite get it's able to take all of our sql scripts figure out if there's going to be a conflict, notifies the QA if needed, and assembles it into one big SQL script that ultimately gets sent to the customer. Then they simply open Query Analyzer and run the script.

I guess that's just as crazy.... it's just that most of it has been automated for us...

Tg

[techgnome]

Thank you for your reply. I'm starting to look at the website now, but I have a question for you about this software and Visual Basic 6 code.

Are you checking VB6 code in? If so, how does it handle the concept of merging code from branch to branch? For us, this is a major issue since VB6 code consists of a textual and a binary file (e.g. .frm/.frx files). I can't get my mind wrapped around how any product can solve the binary merging problem.

In our case, we set a VSS "rule" that frm/frx files can only be checked out by one person at any one time. All other files cls/mod/bas can be checked out by more than one.

Tg

[szlamany]

For cordinating db changes...

We've got this home-grown report writer that takes the recordset of a STORED PROCEDURE and formats it for output on paper. The formatting controls are all stored in a table in the database called REPORT_T. Adding a column to the recordset in the SPROC and tracking that change with source safe is no problem...

...it's getting the one or two new rows into REPORT_T at the customer site that stinks.

We also control what "textboxes" and "grids" appear on our VB app through a table in the DB called (guess what)... FORM_T. Adding a couple of new columns to the SELECT statement in the SPROC, again, is no problem - it's getting the one or two new rows into FORM_T that stinks...

We are very strick about making any changes to the customer control tables - it's all supposed to be done in-house first - but I still have the feeling that a WINDIF check of control tables (whole folder DIF of 10 control tables) is reasonable.

Once we start marketing our application to the national marketplace, I will have to re-think this approach...

[Hack]

In our case, we set a VSS "rule" that frm/frx files can only be checked out by one person at any one time. All other files cls/mod/bas can be checked out by more than one.

Tg

Ditto in my shop.

[RobDog888]

We use VSS here too and have it setup so any file can only be checked out exclusively. Now when VS.NET releases its RTM
version this November we are upgrading to that since it has so many improvements and new features. I like the Remote Access
feature. No longer need to have SourceGears "SourceOffSite" program to give the remote access capabilities.

[Bishop]

Having a team manage it makes a world of difference... In my organization, I am on that team myself, but we are starting to look for better ways to manage the code now.

[Bishop]

In our case, we set a VSS "rule" that frm/frx files can only be checked out by one person at any one time. All other files cls/mod/bas can be checked out by more than one.

Tg

That works for us as well. However, it's a challenge when you have a code branch that has fixes made in the following order: A, B, and C (and all you want to take is fixes A and C).

That's what were looking to solve.. but with binary files, I figured it would be near impossible... that's why I'm very interested in what the community at large uses.

[techgnome]

When we run into that case.... then we "get" fix A.... then we copy the project ot a new folder called "Hot Fix".... check it all into Source Safe, under the Hot Fix folder.... then check it out from there..... make the C changes..... then that's what gets shipped.

It's convoluted and complicatedbut it's a process that's served us well.... and it's evolved over the years too... :P

Tg

[Bishop]

When we run into that case.... then we "get" fix A.... then we copy the project ot a new folder called "Hot Fix".... check it all into Source Safe, under the Hot Fix folder.... then check it out from there..... make the C changes..... then that's what gets shipped.

It's convoluted and complicatedbut it's a process that's served us well.... and it's evolved over the years too... :P

Tg

That's exactly the process that I've helped to develop in our environment as well. This thread certainly has certainly help validate our processes. But it's ashamed that it would appear that there are no better solutions for us.