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

Rasjid Wilcox rasjidw at openminddev.net
Fri Apr 23 23:30:53 EST 2004


On Thursday 22 April 2004 22:13, dominik schramm wrote:
> 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've never used VSS, and I'm afraid we are only talking about a team of two 
developers, but I'll answer your questions (well, as much as possible) 
anyway.

> I'm especially interested in the following points:
>
> 1) Did the transition affect more than 15 developers/users?

No.  :-)

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

Our IT Manager had some reservations about CVS due to the ability for both of 
use to be editing the same file at the same time, as did I to a minor extent.  
Fortunately we went ahead with CVS (over VSS which we did have a copy of) 
anyway.

In practice, there have never been any problems with the lack of a 'locked' 
checkout.  In fact, there is no way I would voluntarily move to a 'single 
user locks whole file' system, since my co-worker and I frequently do work on 
the same module/file (mostly this is Visual Basic) at the same time.  As long 
as both of use are not editing the same *procedure* at the same time, it all 
works very very well, and it would slow down development considerably if only 
one of us could work in a given module at any given time.

Clearly it is not a good idea for both of use to try to work on the same 
*procedure* within a module at the same time, but since we talk to eachother 
and allocate different tasks to each of us, this very rarely happens. (Only 
once or twice in a year).  And when it does happen it is not a big problem to 
resolve.

There are two cases where we reasonably frequently (ie, once or twice a month) 
get 'CVS conflicts'.
(a) When be both add a new procedure at the end of the same module at the same 
time.
(b) When we both make changes to the projects properties at the same time.

In the case of (a), you just remove the 'conflict' markers that CVS places 
into the file on checkout.  This takes about 10 seconds.  You then re-check 
that in, and keep working.  You only get a conflict since CVS doesn't know 
that in general it doesn't matter which procedure is put before the other.

In the case of (b), I just open the projects' .vbp file in a text editor (I 
use SciTE - the brilliant Scintilla text editor), decide what change to keep, 
and save it again.  This generally takes about 30 seconds, perhaps a whole 
minute on a bad day.  Usually it is nothing other than the fact that we have 
drives mapped differently and so have different paths, and sometimes just 
because windows randomly puts the path name to a dll in a different case on 
one PC vs the other.  Anyway, I have never spent more than a minute sorting 
it out (perhaps a few minutes the very first time it happened) - and I just 
check in the fixed version and keep working.

Our last concern was VB's use of binary files for complex for objects.  Again, 
in practice this has never been a problem, and we just make sure that both of 
us are not working on the same form at the same time.  However, for simple 
(non-binary) objects like buttons and menu-items, there have been times where 
we *have* both added objects to the same form at the same time, and CVS has 
handled it without a problem.  In one case the two buttons overlapped a 
little and the form was funny to look at, but it was not a problem.

I should note that we use SmartCVS (see below) as a front-end, and it has 
automatic handling of binary files which works very well.  I can't comment on 
other font-ends or the plain commandline CVS.

> 3) Do you use a "front-end" for CVS or the command line? Or both?

As mentioned, we use SmartCVS as a front-end.  It is not free (shareware with 
function limited free version) but it is not expensive (USD$54 or less per 
user) and well worth the money.  It makes CVS a breeze to use.  *ANYONE* can 
use SmartCVS.  It is written in Java/Swing so it is not the zippiest program 
on the desktop, but I have yet to see a better CVS client for Windows.

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

Sorry - it is only us programmers using CVS where I work.  However, personally 
I could not see a problem with anyone using SmartCVS for basic check-in/
check-out functionality.

In general I can't imagine that non-programmers would need to do merging etc, 
so I don't see a problem here.

> 5) Has the average user's time spent on versioning increased with CVS?
>    What about the sysadmin's time?

As a have said above, I have zero doubt that our development time would 
increase with VSS, since we are frequently working in the same module at the 
same time.  Having to have one of us locked out of a module in order the 
other to do any work in it would be a royal pain in the ****.  Nothing could 
convice me to voluntarily move to such a situation.

Seriously, as long as the team is talking to eachother and knows that A and B 
are working on x, and C and D are working on y, and A and B talk to eachother 
so that A knows that B is working on x.part2 and that B knows that A is 
working on x.part1, there should be no problems.

And besides, resolving conflicts in CVS is not really the big problem that 
pepole seem to think it is.  If two people are working directly on the same 
few lines of code, CVS just includes both versions and expects the user that 
did the checkout to sort out what to do about it.  It is really not a big 
deal.

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

Sounds like cr*p to me.  The vast majority of open-source projects only have a 
handful of developers with CVS commit rights, and patches are normally 
funneled through those people.  Projects big enough for this issue to become 
a problem (the Linux kernel comes to mind) do use something other than CVS.  
But in projects that big VSS and its exclusive locking would be completely 
unworkable.

Conflicts are really not such a big deal.  The person who does a checkout and 
gets a conflict looks at both pieces of code (which CVS puts next to 
eachother with clear markers) and works out how to integrate the other 
persons code into what they are doing.  If they can't do this quickly and 
easily then there are project management issues, not versioning system issues 
at play.

Anyway, I suspect that any time spent resolving conflicts would be more than 
regained by the increased productivity the would result from allowing 
multiple developers to work on different parts of the one file.

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

Um... see my above rave.  I have no idea if this can be enforced server-side 
or not.

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

Why would graphic designers etc need to be doing branching and merging anyway?  
I think this is a red herring.

Just to finish up, I will say that I have been keeping an eye on Subversion 
with an eye to possibly migrating to it so we get atomic commits.  And I plan 
on looking into some of the other options too.  But VSS is not one of the 
options that I would consider (even though we do have a license for it).

See http://better-scm.berlios.de/comparison/comparison.html for a good 
comparison of various (mostly open-source) Version Control Systems.  You may 
find one of them more to your company's liking.

Anyway, I hope that some of the above helps.

Cheers,

Rasjid.



More information about the Programming mailing list