Célio Cidral Junior schrieb:
> Here in my company we are trying to switch from VSS to Subversion, but
> some programmers are a bit reluctant about it.
VSS has two main issues:
1) It uses pessimistic locking. This gives the "somebody else has locked
the file I need, I have to stop working on the issue" headaches.
Pessimistic locking doesn't scale beyond two or three developers.
This issue is solved by "optimistic locking": let everybody change at
his will, but have a mechanism to merge changes if somebody finds that
his changes were concurrent with somebody else's.
Both CVS and SVN have this. Actually every revision control system that
I can think of *except* VSS has this. (Oh, I dimly remember that VSS has
it, too, but it's disabled by default.)
2) The database is in a binary format, and if things get fouled up,
you're doomed. There are recovery programs AFAIK, but when I last saw
them applied, they were only marginally successful. (Besides, the
version history was gone; IIRC the recovery programs don't even try.)
Actually SVN and CVS are nearly indistinguishable from a VSS
perspective. The differences between SVN and CVS are more in the
details: SVN versions entire directories, and hence can manage things
like a file rename, file moving, and multiple update operations; CVS
essentially does things on a per-file basis and loses all aspects that
span multiple files. (This isn't entirely true, but those CVS operations
that span multiple files don't work as "cleanly" as they should. And
file renames were never covered, and never will - CVS' internal workings
simply can't do that.)
> Does anyone knows where
> can I find a list of some of those big companies?
If open-source communities are a hint: SourceForge is currently adding
SVN support. Just throw around a few of the impressive numbers that SF
has, such as number of projects, number of users, etc. - you need not
mention that most of these projects are dead and developers are inactive
(the numbers from big companies will have the same problems anyway).
You might also want to look at the numbers of projects/people at
tigris.org. They aren't as vast as those of SF, but they may be helpful,
too.
> They also claim that all they need is just do check-ins and
> check-outs, and don't want to get "complications".
They also want merges. They just didn't see them work yet :-)
> I think this
> attitude may constraint the development process with rigid and
> problematic procedures.
Indeed. If they lock everything that they work on (that's possible with
SVN), you're essentially back at the VSS development model.
> What's your opinion about preventing the
> development process from using goodies like branching, tagging and
> also the copy-modify-merge model?
The copy-modify-merge model is the most important one.
Branching is helpful, but you can't do that until the programmers have
become used to merging - they won't *want* to branch unless they are
confident that they can merge later.
Tagging is independent of the two. I think they won't object to that -
it's just "mnemonically naming a revision" in SVN. (Remember that SVN
revisions cover the entire tree, so a SVN revision is already equivalent
to a CVS tag - just without the associated processing overhead.)
HTH
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 18 19:40:18 2005