[prog] VSS to CVS -- looking for experiences and argumentation help

[Diggy Bell]

Hi Dominik,

I've been in a situation similar to your's in the past, and am currently
stepping into the exact same situation (VSS -> CVS).

A few years ago I started at a company that was using Perforce for source
control.  Perforce is similar to VSS in that it maintains a server-side
image of what is on your hard drive.  In contrast, CVS keeps information on
your machine relative to your current source image.  This doesn't really
sound like a major issue, but if you have any developers that meet these
criteria, server-side images will cause you severe problems:

1. Remote Developers - The engineer MUST be fully connected to the internal
network to allow VSS/Perforce to check out files.  If the user isn't
connected, the files are read-only on their machine and they can't make any
changes without changing the file system on their computer.  If they do
change their file system, may the coding gods help them...  I've seen a
developer's entire source tree get trashed because they twiddled some
attributes or tweaked some files without properly checking them out (because
of connectivity loss).

2. Flex Hours - A developer may be working on a file when they leave for the
day, but leave the file checked out.  Nobody else can do anything with that
file until they check it back in, even if they are changing a totally
separate are of the file.  Files that are left checked out can cause
engineers to lose an entire day's worth of time if the person who has the
file checked out isn't available.

3. Developers With Notebooks - Some companies have chosen to give developers
notebook computers so they can take them home to work on things in the
evening.  As with pure remote developers, there are some pretty big issues
with VSS/Perforce, and their use of server side images.

We actually ran into all three situations because we had one distributed
team, and one in-house team with notebooks, and flex hours.  The good old
triple whammy.

I'm currently in the process of starting a migration from VSS to CVS at
another client company.  They have had a number of problems with even basic
version tagging under VSS, and severe problems with files being left checked
out.  CVS will make life a lot easier for them.

In terms of GUI clients, this is the one area where I've had the most
problems.  I've gotten WinCVS to work really well before, but I've had some
problems recently remembering exactly how to get it to work.  When it has
worked, there haven't been any issues with usage.  But there may be more
suitable options out there.

Diggy

----- Original Message ----- 
From: "dominik schramm" <dominik.schramm at gmxpro.net>
To: <programming at linuxchix.org>
Sent: Thursday, April 22, 2004 5:13 AM
Subject: [prog] VSS to CVS -- looking for experiences and argumentation help


> Hi list,
>
> There have been three attempts at work to move from Microsoft Visual
> SourceSafe (VSS) to CVS. All of them were abandoned because of some
> -- as I consider them -- minor issues. As I don't regard these
> objections as crucial (or even consider them based on wrong
> assumptions) but can't cite anyone or any company that did
> the migration and has used CVS happily ever after, I'd like to have
> some argumentation help from people who have used both systems and
> favor CVS in spite of all counter-arguments mentioned below.
>
> I'm especially interested in the following points:
>
> 1) Did the transition affect more than 15 developers/users?
>
> 2) Did the transition from "locked checkout only" (VSS) to "locking
>    on demand" (CVS: admin -l, watch/edit...) create any problems?
>    Or did you build some scripts around CVS or made use of the contrib
>    scripts to emulate the VSS operating mode?
>
> 3) Do you use a "front-end" for CVS or the command line? Or both?
>
> 4) How did the developers adjust to the new version control system?
>    How did non-programmers -- who have to put their work under version
>    control as well -- adjust?
>
> 5) Has the average user's time spent on versioning increased with CVS?
>    What about the sysadmin's time?
>
> Here's some background information on my questions:
> 1) Some people at my company fear that a giant chaos would break out
>    if concurrent checkouts were allowed. Some even claim that a
>    considerable amount of time in open source projects using CVS is
>    spent on resolving conflicts from concurrent commits. Is this true?
>
> 2) One major point is that if there were an easy way to force CVS
>    (I'm talking about server side!) to lock checked-out files so only
>    one user can modify and commit any one file at a time, then there
>    would be no more objections to CVS.
>
> 4) Another point that is repeatedly mentioned is that CVS is too
>    complicated for people -- I'm sorry, but I have to put this so
>    harshly, because that's what's being claimed -- who do "dumb"
>    jobs like graphic design or documentation (as opposed to the
>    "clever" programmers), the underlying supposition being that
>    someone who can write complex Java applications has little to no
>    trouble, whereas e.g. graphic designers or QA personnel will find
>    it very difficult to get used to *the concepts behind* CVS (not
>    talking about the cvs command, there are front ends for this), like
>    branching, merging, etc.
>    I'm sure this is completely wrong, since VSS has pitfalls, too, but
>    don't really have proof, of course.
>
>
> Thanks for all feedback.
> regards,
> dominik
>
>
> _______________________________________________
> Programming mailing list
> Programming at linuxchix.org
> http://mailman.linuxchix.org/mailman/listinfo/programming
>
>