Perforce's ability to create and manage changelists is so much better than SVN that I have a hard time using SVN these days. For internal projects, the tracking of who (including yourself) has what checked out is indispensible. For large projects (some of ours are 40+GB workspaces), duplication of all the files and cluttering the file system Subversion-style is unacceptable, so P4 is better here. Perforce's workspace definitions are also vastly superior to SVN. On the other hand, product performance and reliability is an embarrassment after paying so much for a product. New releases of P4V/P4SCC don't support older servers, so even though 6 of 7 servers I connect to are newer, I can't get the bugfix releases or I'm SOL on the older server. Yay for Visual Studio crashing because Perforce development policy blows (assuming newer releases really fix the crashes, I have my doubts)...
Subversion is in position to take over a much larger section of the SCM market, but they really must implement at least the following before it'll ever happen in the workplace. * Option to checkout with no duplicate files and the .svn folder(s) placed outside the tree on the local filesystem. * Server option to require checking out a file before it's marked writable, and a local option to "work locally" on a file, where it's writable but not checked out on the server (Perforce doesn't offer the latter, making it impossible to experiment with files you don't have write access to, even if you never intend to check it in). * High performance for large repos, as in 1M+ files, 1TB+ data. * In addition to Tortoise, an improved standalone UI. Maybe a big revamp of RapidSVN; I'd probably be willing to make it happen if SVN supported the above items.^^ Summary: Subversion is acceptable for loosely-managed projects and teams that can't afford Perforce. For closer teams, Perforce is better almost across the board. Perforce gladly uses their position as #1 as an excuse for miserable product reliability in their GUI tools. Subversion gladly uses their position in the open-source community as an excuse for ignoring the true needs of corporate users. Sam -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Johannes Luber Sent: Saturday, May 02, 2009 10:29 AM To: Jim Idle Cc: [email protected] Subject: Re: [antlr-dev] Why Perforce? > Perforce outranks all the ones you mention by yards as far as most > developers who use it are concerned (well, me at least ;-). I beg to differ. Perforce is annoying with forcing to check out files before you can edit them, as I tend to forget to do that. Furthermore I have to lose the current history view, which forces me to remember the current changeset during the edits and not just between edit sessions. Another problem is the abyssmal handling of moved files. They lose their history and one cannot diff between a changeset before the move with one afterwards. So you have to change the revision number manually. Even subversion does here better. Please tell me, where Perforce has its superiosity compared to other SCMs. Johannes > However, to > get a perforce account, you only have to ask. I agree that the perforce > people not wanting an open read-only login is a bit of a pain and maybe > we should ask them why they want this. > > Also, you can follow the commits on fisheye: > http://fisheye2.atlassian.com/browse/antlr which will give you an RSS > feed as well. > > Jim > > > _______________________________________________ > antlr-dev mailing list > [email protected] > http://www.antlr.org/mailman/listinfo/antlr-dev -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
