[OT] SalesForce + CVS
djk at tobit.co.uk
Mon Sep 14 16:35:18 BST 2009
> Hoi Dirk,
> On Mon, 14 Sep 2009, Dirk Koopman wrote:
>> Raf wrote:
>>> Off-topic, however, we seem to be a technologically broad group.
>>> I'm trying to setup up a strategy to get multiple developers
>>> collaboratively developing against personal -in the cloud' SaleForce
>>> sandboxes and a single CVS repository. We're using the latest
>>> Eclipse plugin and have a strategy which involves local development,
>>> refreshes from server(cloud sandbox) and deploying cvs updated
>>> changes back to the cloud sandboxes.
>> Don't use CVS or SVN.
>> Use something designed for this sort of distributed development model,
>> such as git or mecurial. And you will probably need someone doing QA
>> work on the revisions as well.
> I'm curious as to whether this is based previous experience with
> SalesForce or if this is a best-practice suggestion?
No. Never used Salesforce. In fact I don't know what it is. However, I
am trying to answer the general development case that you outlined above.
> I'd like to understand what advantage something like git would give us
> in this context?
Something like git (which I personally would recommend, but there are
others that could be a better fit to your environment), is designed from
the ground up to allow simultaneous and "multi-threaded" development.
Neither CVS nor SVN work well with this sort of independent development
model that you are suggesting.
Without getting into religious wars about it, both CVS and SVN are
designed for individuals or (very) small teams to be working on one
problem at a time on a particular unit of source. A "checkout/update",
"develop/fix", "checkin" model. The moment one has more than one
individual/group working on the same unit of code, one needs
coordination and very careful checking in/updating otherwise one get
rapidly into the sort of muddle that you describe. It is very easy to
get into the "he whom commits last - wins" syndrome. Except that it
quite easy for that to become ".. last - trashes the repository" as well.
Some of the advantages include:
* inherent support for simultaneous development, this specifically what
it is designed to do. In fact, why it was written in the first place.
* very flexible repository structure within a organisation (one central
repository a la CVS/SVN, multi-level (staging/production/play) or no
structure at all)
* atomic updates (at the git level)
* easy branching thus experimentation.
* easy and reliable merging.
* fast (certainly in git's case).
* very good history and tools for discovering what's happened and where.
* reliability - it is hard to trash things and because of git's
repository model, one gets as many backups as one has developers (at least).
More information about the london.pm