+ Start a Discussion

Force.com IDE and Source Code Management between multiple developers



I am part of a small group of developers (5) working concurrently on a salesforce app.


I have been able to setup Force.com IDE (on Windows, "Eclipse IDE for Java Developers", Java JDK/JRE update 6u27), and I am able to my developer account.


  1.  Can multiple salesforce developers share on deverloperForce account or salesforce app source repository?
  2.  If so, then can existing salesforce developers be assigned to a shared account, or will these developers need to be assigned a new developerForce account?
  3.  If multiple developers can work against a shared account, then is it possible for multiple developers (each using Force.com IDE) to work concurrently on a single developer account as if a "source code management"?
  4.  In other words, "Force.com > Save to Server" and "Force.com > Synchronize with Server" detects conflicts and avoids over-writting other changes?

Thank you


Jeff in Seattle


Note: Using Java JDE/JRE update 7u5 failed with "Force.com > Save to Server" requests.




Each developer could check out the code under the same SF account/username, but it is preferrable for them to have their own username, in my opinion.  This way you can better track who made which changes.  Also, the Web UI (i.e., Salesforce) shares some session state at the user level.  For example, if two of you are logged into Salesforce under the same username and one of you changes to a different App Salesforce will change the other user to that App as well.


As far as not overwriting changes...even if you are the only one working in your org and you modify something on the server and then try to save a change from your IDE that would overwrite it, the IDE will prevent you.  You will see an error in the Problems view.  You'll be able to Synchronize and reconcile the differences.


Check out this document from Salesforce: http://www.salesforce.com/us/developer/docs/dev_lifecycle/index.htm.  It describes some ideal scenarios/practices for team development; however, in practice, I ran in to SF bugs (and unreasonable / overhead) which made most of the recommended best practices in this guide not practical for me to fully implement.