>We are currently developing here with 3 programmers, and we have more and more conflicts using the same projects.
>
>Can Visual sourcesafe be a solution for us ?
It can certainly help. At least you have a record of who checked files in/out and at what times. If developers are diligent about entering comments upon checkin and/or check out, it can also give a decent "file history".

>Doesn't it create new problems, will solving some existing ..
This is the primary reason for my post. VSS imposes some restrictions and assumptions that you may or may not be comfortable with.

1) VSS uses the paradigm that a directory (or folder) and a VSS "project" are the same thing. In other words, if you are used to organizing source code in a directory structure like this:

root\
prgs
libs\
reports

then VSS considers each directory a separate "project." You either have to change the way you organize source code, or manage multiple VSS projects for what you might normally consider to be a single project. This adds complexity and time to the task of setting up and managing source code.


2) In a team of 5 developers working on a single project, we found that the widely used file type-based organization of code becomes increasingly inefficient the more developers you add to a project.

For instance, if all the forms in your application reside in a file named AppForms.vcx, then when a developer wants to work on just one form, he has to check out the *whole file*, thereby locking out other team members from editing *any other* form in the project. VSS does not support multiple checkouts of binary files, including SCX, VCX, MNX, and graphics. This is an important issue to consider when planning.

One workaround is to reorganize class libraries by "module" rather than file type. IOW, if you have an employee module consisting of 1 or more employee forms, employee-specific business objects, employee rules, etc., you would put them all into a single VCX: Empl.vcx. When a developer wants to work on the Employee module, he just checks out Empl.vcx, and possibly Empl.prg. He doesn't have to check out an AppForms.vcx containing *every* form in the app.


>Does it take long to get it running ?
That depends on whether you decide to make changes like those above, or whether you're all set and just install and configure VSS.


>Does also work with FP DOS 2.6 projects (yes they still exist ...)
As someone else posted, yes it works fine from the VSS Explorer window.


>Are there alternatives ?
I can't give you a straight answer on this, but there is a lot of movement in the source control marketplace, with new web-centric products being introduced - I've seen several ads in programming magazines. I haven't tried anything else, though.

Final VSS comments: If you use VSS, I recommend keeping the "master" files on a server, and each developer keeps a full project "copy" on his local hard drive so he can do "private builds." A developer can check out a file to his local drive and try something "radical" with it, test it, and if it's a dead end, he can simply "Undo checkout" and roll back to the original. The official "build" on the server is never compromised. This gives the developer a great deal of freedom.

As a manager, you might like to know whenever a developer has a file checked out for, say, more than 2 days, then you check with the developer to make sure he isn't "stuck" on some issue.

I hope this helps, and does create confusion. Implementing "formal" source control is not just installing new software; it may change the dynamics of the development team.