[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