Post by The DoctorI am in C# development team. I am very very new to C# and for
that Windows development. The lead developer have had problems
with CVS using Tortoise CVS as the client.
Notes:
1) There is a separate newsgroup/mailing list for TortoiseCVS:
http://tortoisecvs.org/support.shtml
2) TortoiseCVS is primarily written for use with CVSNT (free/GPL just like CVS and runs on Linux/Windows/Mac/Unix) and in fact includes the CVSNT client not the CVS one.
CVSNT is NoT CVS.
Post by The DoctorOur lead developer and project manager have got so sick
of the problems that they want to switch visual source safe.
Can you be specific about the problems. Are they TortoiseCVS problems (in which case you should report them to the TortoiseCVS mailing list) or are they CVS problems (in which case you need to determine if your team(s) have business requirements that cannot be met using the tools provided)?
Post by The DoctorI feel uncomfortable because I think it is a backward step.
Tools are tools - they exist to help you solve business problems.
If the developer simply wants to use VSS because it's what they are familiar with, or they want to use SVN/Git because it's the latest toy then it's good to stand up to 'on principal'. But otherwise I think it's wise to get in and ensure that the tools do help the business not hinder it. Remember that one of the beauties of Free Open Source Software is that you can adapt it to ensure it works well for your organisation.
Post by The DoctorCould it be that they are just not using CVS
properly.
It would help to know the problems as reported first, and then maybe some insight to the 'problems behind the problems'...
CVSNT 'forked' from CVS years ago because there were different schools of thought about what functions are useful in a version control tool. Notably VSS uses a SCM methodology that is 'distributed reserved' wheras CVS uses 'distributed unreserved' (also called concurrent) - we made modifications so that CVSNT can also work like VSS 'reserved' and also support 'centralised' modes (where developers share a single sandbox) - because we are not particularly wedded to an SCM methodology.
Of course if your organisation only uses one methodology and that is supported by CVS then the 'choices' in CVSNT complicate matters - making CVS a better choice. But maybe what you are finding is that you C# team have genuine good business reasons for using a different SCM methodology and now would be a good time to select a single tool that can support all your teams. And yes - that's where I think CVSNT does a better job than SVN, CVS, VSS, PVCS etc etc. CVSNT 3.1 (now called EVS) even allows some developers to use SVN clients, some to use MS TeamSystem clients and others to use CVS or CVSNT clients all with a single repository.
It could also be that your C# team need professional training, or they need more support or they need to know that they are being listened to and that their ideas have as much value as yours.
Of course someone is bound to eventually point out that VSS is unreliable and that its easy to lose your version history. But that just will move the argument from being about CVS vs VSS to CVS vs MSTS,s o I won't bore you with that.
Regards,
Arthur Barrett