I am with a small start-up company that uses Subversion, but we are
quickly gaining notice in the console games industry. The company name
is High Impact Games, and we are working on the next Ratchet and Clank
game for the PSP, under contract with Sony. All of our source code,
art, tools, and output data is tracked and distributed between
production staff via Subversion.
We handle a huge amount of data per project (now exceeding 20GB,
200K+ files), with strict security and permissions limits, but we
still manage to provide access to offsite workers (through encrypted,
password-limited, white-listed connections). I managed to do all this
with zero server software budget, on relatively low performance server
hardware. We wont have the budget for bigger servers or software, or
even Subversion pay-service providers, until we start seeing returns
on our game sales.
We haven't evaluated paid support like CollabNet yet, because
there are some speed concerns with the Subversion client. We are stuck
in the Win32 Stone Age (due to specific art tool requirements), and
Subversion is not as fast on NTFS as *real modern filesystems* like
ReiserFS. Subversion requires a lot of directory-walks for safe
recursive updates and status checks, and this can be slow on NTFS with
100K+ folders and 200K+ files. That is the main reason I'm having a
hard time convincing the money-decision makers here, to hire work on a
custom set of Subversion client tools to speed things up, rather than
going with an SCM with a more centralized (faster on NTFS) Working
Copy cache model -- like Perforce. It's hard to see changing something
as fundemental as the current Working Copy per-folder cache system,
even with a "bribe" to the development community, of total Perforce
license cost or greater (roughly $9000+), combined with the time of
one or two internal developers. The needs of the larger Subversion
community far outweigh our own internal needs.
Having said all that, I have to respectfully disagree with Andrew
Reedick on a few points here...
Andrew Reedick wrote:
[snip, discussing Subversion cons]
> * it doesn't have heavy permissions
Actually I've been able to configure very tight permissions,
automatically coordinated with Windows Domain and network-storage
authentication via LDAP. Permissions configuration can get even
tighter now, with the new authz features in recent svn server
releases.
I have also accomplished tiered permission settings based on
subnet, allowing users on the "trusted" LAN segments to access Repos
read-only without authentication, only forcing authentication on
commit. "Untrusted outside" IP's (which are still white-listed) are
forced to use authentication and encrypted connections on all
transactions. A lot of these forms of authentication, port access
limits, and white-lists are more appropriate to implement with systems
outside the SCM server. Subversion gives plenty of flexibility in
using the encryption and authentication system most appropriate to
user environment, whether Enterprise or SOHO.
It was a very smart move for Subversion to utilize Apache network
connection and authentication capabilities, rather than re-inventing
that wheel yet again.
> * it's also why Subversion has server side hooks instead of
> client side hooks. Client side hooks allow you greater control and
> information management which is very nice (and almost critical) for a
> coporate LAN.
The Subversion SDK, and svn client's parse-worthy stdout, make it
pretty easy to implement wrapper tools rather than "client side
hooks", which I think is more appropriate to corporate environments.
Even GUI clients like TortoiseSVN are starting to implement extensions
and hook-like features.
Subversion is not associated with any de-facto GUI, which makes it
easier for corporations to decide on the best interface for their
specific environment. My biggest problem with closed SCM systems like
Perforce is that you're stuck with one client option only, on any
platform they *choose* to support. Even if it's a really good client,
if it is missing something you want or need, there is no hope in
getting that from a different client, or from another vendor. There's
absolutely no market incentive to support someone else's license-fee
cash-cow like that. In contrast, there are plenty of Subversion GUI
options, OSS/free or closed-source/fee, for all platforms. Even if you
implement your own GUI client, you have a lot more control over your
GUI feature direction than with any closed SCM.
> I don't think it's a case of developers ignoring the audience, I
> think it's a case of corporate customers ignoring Subversion's goal of
> providing open-source developers with a version control system that can
> support developers world-wide.
We have some offsite workers using the same repositories as the LAN
users, which the Subversion design enables cleanly, but that's a
limited example. A better example is the large corporate trend towards
outsourcing, which usually involves local teams collaborating with
offices accross the globe. I think there is a big corporate audience
participating in this trend, that can benefit from Subversion as-is.
In our case, client optimizations for Win32 environments would
help most, like a centralized WC cache system, both on the LAN and
"world-wide". I like FSFS so much, I would like to see it used as a
Working Copy cache and status storage system as well as a server
Repository store. This might also bring Subversion closer to
usefulness as a distributed SCM, like SVK or Mercurial. I know that's
not a central design goal at all here, but I like to daydream... :)
Since Microsoft was mentioned here, I must say if you are
considering VSS at all, stop right now. I spent more time fixing
corrupted VSS repositories than any other VSS repo operations in past
jobs, and that is a hell I don't ever wish on anyone else. I also
found CVS very painful to use with binary files. If you don't want to
spend the money on a really "high-end" closed SCM like Perforce or
AccuRev, stick to Subversion instead, and spend your time evaluating
the many GUI clients and SLA provider options.
Just my opinion,
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 13 12:20:13 2006