5

I have a question about the Force.com IDE in Eclipse along with SVN (subclipse).

For the sake of this question, we have two developers, Harry and Sally, working in the same developer org. They both do their development in that org as well as pull changes to their local Eclipse environment before commiting to SVN. Let's say Harry adds a new field to the Account object. He tests it, sees everything works as intended, so he refreshes everything in his Eclipse to commit to SVN. However, during the time Harry was testing his new field, Sally creates a seperate field in the Account object as well. But, she has not tested it by the time Harry refreshes his changes from the server. Harry now wants to commit his changes to SVN, but notices there are additions to the Account and Profiles code he did not make that include the new field that Sally added. He now needs to manually delete these extra lines of code in every effected file before committing his stable changes.

My question is, is there a way for Harry to pull only the changes on the server that were made by him? Or is there a better way to handle the manual deletion of Sally's changes before he commits to SVN?

Improve this question
2
  • I am not sure if SVN is supporting this but you can always commit your own piece of code by seeing the difference and leave the others. Instead of removing. This happens in GIT repos. During merge you will get both changes as the same way other developer will leave others changes.
    – Ashwani
    Commented Jan 26, 2017 at 17:11
  • Ryan, I know this is not exactly an answer... but this is a good case for multiple environments.
    – Sebastian Kessel
    Commented Jan 26, 2017 at 17:12

1 Answer 1

Reset to default
4

Harry and Sally should not be sharing a development org. They should each have their own development org, so that they can each pull in just their own changes, and merge those changes to a branches that will ultimately be used to build other orgs downstream (qa, uat, and production). Sharing a development org between developers is error-prone, and will likely lead to loss of code and productivity.

The Eclipse IDE, and the Metadata API itself, is unable to distinguish between changes made by any particular admin in an org, which is why multiple development orgs are a requirement for successful CVS processes. Salesforce is working on new features which will help facilitate multi-developer-org scenarios, but we're still months away from GA for any of those features.

Until then, if you must share a development org, each developer will have to manually select just the files they've modified, and then right-click on those file and choose "Refresh from server." Selecting the entire project and choosing "Refresh from server" would incorporate all changes made to the metadata from all developers in the org.

In addition, if you choose to pull all the metadata, you can always commit just the files you're interested in, then rollback the changes for everything else. The process used will depend on the CVS. For example, in Git, you can see the full list of files modified in the IDE, compile a staging list, and then commit and push those changes, followed by a Hard Reset to get everything else back into their original state. I don't recommend this, as this is basically the process we're using now, but it works as long as each developer is careful.

Improve this answer
2
  • Hi sfdcfox, thank you for your response. The reason I had Harry and Sally in the same development org is because that is how we have our CI setup at the company I work at. Every developer makes their own changes, and commits only the files they edited to SVN. Jenkins then notices the changes to SVN, makes a build, and deploys it to our packaging environment where a dry run of SIT takes place. How, in the case of having each developer using their own dev org, would all the developers commit to the same SVN without having a full copy of the repo in their environment?
    – Ryan Coombs
    Commented Jan 27, 2017 at 16:51
  • @RyanCoombs Yes, we're moving to our own process, and it's been a bit of a learning curve, but our environment is set up as follows: (each developer has a developer org) -> (a common qa org) -> (a common uat org) -> (production). This is based on the best practices established by salesforce.com, and is the recommended process for Salesforce DX. You might want to sign up for the pilot if you're interested in moving that direction.
    – sfdcfox ♦
    Commented Jan 27, 2017 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .