On 2008-08-26 at 23:37 -0700, Joshua Juran wrote: > What I hate the most is that everybody still uses Perforce anyway[1], > even though the deficiencies don't get addressed[2], even when much > better free alternatives exist, due I guess to inertia and the cost > of switching.
For certain types of work, changelists are a nice model and being able to easily get a diff of everything changed in one submit, without having to faff around finding dates and subtracting a few seconds, etc, is nice. Subversion 1.5 introduces changelists; I know of at least one largish company where this has been the blocking requirement for migrating P4->Subversion. DVCS offerings are not really an improvement over Subversion here, when company-owned source code on laptops is forbidden anyway and you do want to make sure that all work makes it into one repository eventually so that it can be tracked and any code run in a production environment can be required to come from that repository, not some private DVCS instance where nobody know's what's really being compiled). DVCS has its place. Volunteers, or no central control, or each contributor being able to have their own local control are examples of where it truly shines. But it's not a panacea or the only possible correct model. > [2] How do you reverse a submitted change? $employer uses a wrapper around p4 which provides site-local extensions and we do everything via that wrapper, which passes through unrecognised options. I'd never realised before that the 'rollback' sub-command is one of those extensions; "$p4 rollback -c $CL". So, I guess part of it depends upon how good your repo admin are. ;) FWIW, this is possibly the first time that I've come close to defending P4. My preferred poison is Subversion; I understand the DVCS model and git, etc, and see why they're popular for developers, but if you're a sysadmin maintaining system configs, having a central canonical configuration, which can be edited with locking, is still useful. Alas, too many people refuse to see that anyone else can legitimately have different requirements and become bigots saying "Only distributed VCS should ever be used", right before launching into boring holy wars about which one will rule the world. Subversion falls down in not having permissions control at all; there's some wrapper which lets you auto-set the permissions based upon a property, but the wrapper doesn't bother locking down the permissions on the .svn directory so you've lost. Secure private content (trusted repo admins) is a pain with svn, impossible with a dvcs, and barely tolerable with some other systems, such as P4 or CVS. :( Sure, you can encrypt first but you then lose diffs and you're back to "how do you keep your encryption keys around, long-term, and manage granting/revoking access to old content?". The use of checksums chaining diffs together is a nice idea in git; a pity that it's touted as making git more secure than alternatives, when it uses a broken checksum algorithm (which was known to have serious problems when git was written) and in such a way that migrating to a new checksum algorithm is perhaps less easy than might be desired. -Phil
