RE: Pitfalls when using CVS in windows

[Arthur Barrett]

> I 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.

> Our 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)?

> I 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.


> Could 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