[OT] SalesForce + CVS

[Dirk Koopman]

Raf wrote:
> 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).


Dirk