Célio Cidral Junior wrote:
> Hi,
>
> 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?
>
> 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. What's your opinion about preventing the
> development process from using goodies like branching, tagging and
> also the copy-modify-merge model?
I put a VSS database in a company where I was working back in '99 as
well. I'm not sure whether they're still using it (or if they've
switched over to a new source control package... I should ask). At the
time, they weren't using *anything*, so VSS was better then nothing and
we already had licenses for it. In my current company, we're using
SourceOffSite with VSS because most of the group works offsite. The
cost of the SOS/VSS licenses, however, is a strong reason to migrate to
something else.
I'm in the process of migrating my personal development repositories
from VSS to SVN, and setting up SVN repositories for some side work that
I do. Once those two tests are finished I may move the company away
from VSS to SVN.
About the only thing that isn't in SVN yet is sharing, which we use
extensively in VSS/SOS. That's supposed to get added at some point, but
I'm also thinking about ways of doing without. (Sharing is very useful
for managing things like websites where you might have a skeleton file
that is identical across multiple folders, with changes managed in
individual include files that aren't shared.)
Copy-modify-merge model is something that I'm not sure we're going to
use if we move from VSS to SVN. A lot of what we share between
co-workers in this distributed setup are binary files (documents,
spreadsheets, database files), which aren't suited to copy-modify-merge.
(Not sure if we can setup 2 types of systems. Copy-modify-merge
for text files and a reservation-style system with read-only flags for
binary files. That would be the best of both worlds.)
One nice feature of SVN is that there are multiple clients. That opens
the door for end-users to pick client software that they are comfortable
with. Whether that plays out well in real life... I'm not sure yet.
Our current evaluation involves using TortoiseSVN+PuTTY over SSH, but
I'm waiting to see how well it scales with 100-200k files and a few
dozen GB of data.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 22 21:45:44 2005