Which Version Control SW works best with VFP?

[mkrausnick]

I'm looking for recommendations for a version control system to manage my VFP project library. I have about 6 active projects and growing. I also have a common library of PRGs and forms that serves them all.

Thanks!

Mike Krausnick
Dublin, California

 

[Olaf Doschke]

Source Safe:

http://www.hentzenwerke.com/catalog/essvss.htm

CVS or Subversion:

http://www.foxpert.com/docs/cvs.en.htm

Sourcegear Vault:

http://www.sourcegear.com

You always have to face the problem that source code conrol/version control systems handle VCX and SCX as binary files, which does not enable you to merge modifications by two users, so plan your VCX granularity accordingly, so that one user is responsible for a class library.

Bye, Olaf.

 

[Neil Toulouse]

We have just dumped SourceSafe after using it for many years as we had continued problems with it (old code turning up in builds etc). Info from the Net seems to suggest you should use anything BUT SourceSafe! Oh well you live and learn

We have recently moved to SubVersion, and seems to do the job just fine (although we have literally only used it for a few weeks, so maybe too early for a proper analysis). Just keep in mind what Olaf says about binary files, but you can lock files out for editing. This of course is only an issue if there is more than one of you doing the work!

We use it too keep track of about 10 projects on the go at any one time, with at least 2 developers on a project. We also use TortoiseSVN as the client side link to the SVN repositories, and have just started to use BugTracker for our bugs/change requests which links in to SVN also.

Neil

I like work. It fascinates me. I can sit and look at it for hours...

 

[Dan Freeman]

We have just dumped SourceSafe after using it for many years as we had continued problems with it (old code turning up in builds etc). Info from the Net seems to suggest you should use anything BUT SourceSafe! Oh well you live and learn

Interesting. I've used VSS since MS bought it and have never seen this problem.

Most of the "problems" I've seen reported aren't problems at all, but just the way VSS works. People are constantly trying to make VFP work the way they *wish* it worked instead of accepting/embracing the way it *actually* works. Same with VSS, I suspect.

 

[Neil Toulouse]

DanFreeman

We used VSS for many years without an issue. Our use of VSS was very, very simple, ie checkout, do whatever, then check-in! Nothing more than that, and therefore suited our purposes fine!

BUT, we kept having builds where old, bugged code would creep back in for no reason, meaning we would have to issue another release of our software shortly after the official one! And this could also suffer the same fate, meaning yet another release. And sometimes another. Then we began to look a bit of a joke with our clients (unacceptable).

We have a very extensive testing regime. So even if they (the testers) had signed it off, and we created a final build for the release we, more times than not, ended up with old bugs (that had previously been fixed) in the system.

Then after reading various horror stories on the Net that seemed to match the experiences we were having, I made the immediate decision to dump VSS and go for something else.

I am not a Microsoft fanboi, but neither to I despise them. But when I read somewhere that they do not use it for their source control, it made me think!

Anyway, with SVN, so far no horror stories! but still a bit to early to give a proper analysis.

Will keep you posted...

I like work. It fascinates me. I can sit and look at it for hours...

 

[Neil Toulouse]

...and just to add these problems we were getting have occured consistently now for the past 2 years!!!

I like work. It fascinates me. I can sit and look at it for hours...

 

[RoadRunnerOz]

We use VSS to back up our wip files.

Ex:
Library1
Class1
Class2
Class3

If user one wants to change Class1 (s)he simply creates a wip library with just thst one class and removes the original from their project: wip_Class1

Should two developers require the same class, they would use the Task No as an identifier: wip_Class1Task1234

When it is time to for a new release, the second developer is responsible for merging his/her code into the first developer's wip file. Then a designated developer (always the same) moves the merged class(s) back into the build project.
Once the build is perfected, this also is put into VSS and each developer gets a copy of the new project files to start all over again.

This isn't 100% foolproof but has worked for some time with up to 15/20 developers.








Michael Ouellette