Team Programming Approaches 1

[DennisKeith]

I am having a good bit of trouble with source code management in VB in a team programming environment. For the second time in two weeks, we have essentially lost a day's work of work due to inadvertant overwriting. We are not using Visual SourceSafe since I couldn't find a good manual on the product and several attempts to use it without real understanding proved to be pointless - it slowed everyone down and didn't protect the source.

Our current approach has been to divide by functionality. That is, all functions of the same type go into the same class/module/dll. At this stage in the development, most of the code is in modules. Since some of these modules might cover things like 'inventory checks', they can have more than a few functions with the result being that they are worked on by more than one author.

Common functionality is stressed and this has caused most of the problems. For instance, we have a module called FlightInfo which contains functions that accept and return objects dealing with airline flights. One programmer might work on this module as used by the object Fubar while another will work on the same module in object Fubar2. The results are not pleasant.

Any suggestions would not only be appreciated but read very carefully. I am open to almost anything at all. I don't know what will work but I do know that our current setup does not.

Thanks

Dennis Keith

 

[cyberbiker]

I had a similar issue working a language called PL/N with only one other guy in the office (the boss, so you know who got the blame!)
My only solution was to keep what I worked on seperate and zipped up. Then I compared files before overwriting anything to see if there were any changes. It did not work real well, but it got by.
I also had similar in Cobol in a UNIX system. There I saved anything I worked on with my initials as the extension. Again, comparing files before overwriting.
Do not kmow if this helps since both languages I had the issue with were text based.
Perhaps I can stir things up a bit and somebody can come up with a decent solution!

"Don't Trust me. I have no idea what I'm doing"
Terry (cyberbiker)

 

[chiph]

Dennis -

SourceSafe (VSS) is project-oriented, so what you do is go into VSS and create a new folder/project. For each project, VSS has to know what your working directory is (where you do your work). Lets say your project name is WhizzoApp. You would set the working directory to something like C:\Src\WhizzoApp

Copy your existing source code into that directory. You then add those files (*.frm, *.bas, *.cls, *.vbp, etc) to the project. When you do this, it sets the read-only flag on those files in your working directory to protect you from making inadvertant changes.

When you're ready to work on a module, you go to VSS and do a CheckOut on it. VSS copies the latest version into your working directory (after all, someone else might have made changes since the last time you touched it), and clears the read-only flag. No one else is allowed to check it out until you're done with your changes and do a CheckIn on it. Now go to C:\Src\WhizzoApp and load up the VBP and start working.

Every so often (I do it in the morning) you need to do a GetLatestVersion on those files you don't have checked out. This refreshes your working directory with everyone else's changes, and makes sure that you've got the latest and greatest.

When it comes time to build a DLL or EXE, you check that file out (hopefully on a dedicated build machine to be ensured of the correct build environment), build, and then check in. You would then apply a Label to the entire project so that if you need to go back to that version at a later time, you'll be able to find it in VSS's change history.

In your message you said that source modules can be shared amongst components. You can handle this situation in VSS by having separate projects for each component, then Sharing the source module between the projects. The verbage on VSS's dialogs is a little misleading, but basically it results in the same file appearing in multiple projects. Only one person can check that module out at a time, and then only into one project at a time. It must be checked in from that project as well.

One other thing, VSS integrates in with the VB IDE via an add-in. This works well, but my personal preference is to manage my source code control outside of VB, so that I'm more conscious of what I'm doing. Do whichever suits your style best, they're both good.

Hope this gets you started, it sounds like you definately need a source code control system.

Chip H.

 

[jfrost10]

Hey Dennis,

Just wanted to throw my $.02 worth into the discussion. I work for a company coming to the tail end of a huge VB project as well, and here's how we fared:
Our setup was like a wheel. We had one person who assigned coding assignments to everyone. When people completed the coding, the just sent their files back to her to integrate into the collective mass. Programmers were responsible for backing up on their own machines, but our project lead acted as a moderator for what got saved on our development server. That way, there was only one hand in the cookie jar at any one time.

Good luck with the rest of the project!


Jack