On 11/18/05, CÚlio Cidral Junior <firstname.lastname@example.org> wrote:
> Here in my company we are trying to switch from VSS to Subversion, but
> some programmers are a bit reluctant about it. It's well known and
> already proved that VSS is weird, limited, buggy and problematic. One
> of the questions was about what big companies are really using
> Subversion in their development environment. Does anyone knows where
> can I find a list of some of those big companies?
I'm a recovering VSS user. My previous employer used VSS (actually, I
was one of the people who implemented it in '99) and I'm about to roll
out SVN at my new employer. In my research, I found that most "big
companies" tend to purchase big-money comemrcial version control
systems and spend a lot of money putting them in place
Check out some of the better-known OSS projects like KDE and various
Linux distributions. Several of those are in the tens of GB of data
being managed by SVN, with hundreds or even thousands of developers.
> They also claim that all they need is just do check-ins and
> check-outs, and don't want to get "complications". I think this
> attitude may constraint the development process with rigid and
> problematic procedures.
I think this attitude represents an already-constrained view of the
development process that your developers hold. Maybe they feel this
way because it's all that they've been able to get out of VSS, I can't
say. I know when I was using VSS, we didn't use it for much more than
this, and the exclusive locks and inability to merge (that I recall
seeing, anyway), led to a lot of headaches and lost productivity.
> What's your opinion about preventing the
> development process from using goodies like branching, tagging and
> also the copy-modify-merge model?
We used tags w/ VSS a little bit, but not their full potential. Which
resulted in every time I had a new release of my project, I had to
send a list to our release managers saying "move version X of
file1.asp, version Y of file2.asp", etc. If we were exploiting tags,
I could have just said "grab tag A" and been done with it - and had a
record in the repository to reproduce the activity later if needed.
SVN makes this both cheap (disk space) and easy, or you can skip it
altogether and just use revision numbers - but then you have to keep a
record of those key revisions.
As for copy/modify/merge, I'm heavily preferring it over VSS's model.
With VSS, if I needed to make a change to a file that someone else had
checked out or locked, I had to negotiate with them to "timeshare" the
file and manually merge our changes. If that person was out of the
office for a day or a week, my work had to halt, or I'd have to ask an
admin to remove his lock, and then figure out what to do when the
other developer returned. SVN makes this so much easier - we work
independently and then merge when we commit. My work doesn't stop
because someone else is working on the same file.
As a former VSS user and soon-to-be SVN user, I don't ever want to go
back to VSS. I'd rather have no version control than use VSS.
The ONLY benefit VSS offers is integration with the old-school MS
development environments - Visual Studio (previous to .NET) and Visual
InterDev. I've never heard of MS making significant use of VSS
themselves! That speaks volumes. I don't know how many of VSS's
warts you've uncovered, but the two I was hurt by the most are
database corruption (there's 3 kinds of VSS users - those who have
suffered a corrupt DB, those whose DB is corrupt and they don't know
it, and those who will have it happen soon) and the inability to get a
usable backup of the DB without having all users logged out of the
system (this is partly a fault of the tape backup software as well for
not backing up open files, but if you have the VSS client or a
VSS-integrated IDE open and pointing at your DB, files are open). We
had a massive corruption of our DB in April and discovered we had NO
usable backups because of this.
Sorry, I tailed off into a VSS-bashing spree there, but wanted to
point out that VSS isn't "good enough" no matter what your developers
may think - it's horribly flawed.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Nov 18 18:24:33 2005