Hi Nebocreek,

Thank you for your post.

First of all, I should say that the case when you have more than 200 files with local changes causes the error due the SF limitations.

Please, use the Build option for the less count of the changed files inside TWS.

We will add the force-write functionality to the IDE, but I cannot tell you when exactly this will be done. 

Our team will investigate your suggestion about this configuration and I'll keep you informed about any improvements related to this.

Regards,

Kate

Hi, 

We work in a configuration where each developer has their own Salesforce sandbox environment and local changes are merged with other developer changes via subversion. This doesn't seem to be a configuration that TWS supports. I realize SVN isn't currently supported but if TWS would allow force-write to the server it would be great. 

Often while trying to use TWS I'll get in a situation where I have local changes to >200 files and Welkin simply errors out. Essentially, I need my local files to be the source of truth and the IDE to push changes to the sandbox so that they match. I've found that if I turn off local history and only sync classes, pages, triggers and components I get closer to a working situation.

Is there some configuration that supports this situation? If not, I would like to request it.

Best Regards

This functionality would be really great, but I could see this being extremely difficult to implement.  The holy grail in my opinion would be the ability to utilize source control as the single source of truth, storing a snapshot of the entire org (click and code configurations).  Ideally you'd want to be able to pull the entire source org's state and overwrite the target environment with the corresponding metadata.  If you've ever worked with the metadata API, it becomes quite apparent that the limitation is on SF's ability to handle large changes with conflicting dependencies.  I think auto-generation of the build.xml and destructiveChanges.xml files could help with keeping orgs synced up, as long as a structured development approach is followed.

Hi nebocreek, dclappert,

Right now we're mostly thinking of the way of working with TWS and version control when all developers are using TWS and source code in the version control is TWS project itself. In this case there should be no issues (in most cases).

I'm not exactly sure yet if we will add an option to do a "force build" or how exactly this will be done. The reason is that doing such change is more of a workaround instead of fixing a gap in the supported workflows - we'd prefer to provide proper support of different development workflows.

Can you please describe your development process in some more details? This way we will be able to reconstruct your situation precisely and will try to come up with a good decision that would benefit everyone :)

If you want you can email me directly - vladimir.gubanovich@welkinsuite.com

Thank you once more for your suggestion - it is very important for us.

Thanks,

Vladimir

Hi and thanks for the response.

In our process, each developer has their own Salesforce sandbox environment for development. Once a developer is happy with their local/sandbox changes, they use SVN to check in their changes to the shared repo and we have Jenkins/Ant send the changes to a shared Salesforce environment for testing. After that code changes move through other Salesforce sandboxes for QA, User Acceptance Testing, etc. until finally being deployed to production at the end of a sprint.

At the beginning of a new sprint I start by pulling down a copy of the latest code (from our shared repo) to my machine via SVN. Then I'll usually use Sublime/Maven's Mate to save that code to my Salesforce Sandbox and compile. Then I can use Sublime to make code changes locally and compile them to my Salesforce sandbox. When I'm happy with my changes, they are merged with other developer's changes using SVN/Jenkins/Ant. Then they move through each phase of testing, etc.

I'd prefer to use TWS but even if I do all the previous steps outside of TWS and then make a new project and pull the code from my sandbox I get lots of changes between what I have locally and what the SVN repo has. Most of these changes are insignificant such as white-space, capitalization and single-quote vs. double-quotes, etc.

I really wish I could just tell TWS to save my local changes to my sandbox. Somehow, I always end up in this situation where it thinks my sandbox's changes are newer than the ones on my machine so no matter what, my local changes can never be written to my sandbox so I can't ever really do any work. It's been super frustrating because I really like TWS and would really prefer to develop on it. 

I've tried about every configuration I can but TWS seems to want my local files to always exactly match what's in my sandbox which doesn't really make any sense. That's why we have an IDE in the first place is to make changes to the code, right?

What would be nice is the following:

1. When comparing server vs local changes, allow the user to choose which one to keep and write that file to the server
2. When comparing server vs local changes, allow the user to merge the two and write th result to the server
3. An option to select a) disallow overwrite of server changes b ) allow overwrite of server files with warning c) always overwrite server changes

As it is, the only option we seem to have is to always discard local changes in favor of what's on the server.

Hi nebocreek,

Thank you for such a detailed description. We will go through the similar workflow and will try to find out the best ways of resolving issues you've mentioned, but we'll also aim to keep the current logic which saves developers from overwriting each-others changes on the org.

Just a very quick question - there is an ability to merge your local files with files on the org from The Welkin Suite, have you tried to fit that one into your workflow? In case when you receive an error from TWS saying that you can't overwrite changes on the server you need to pull changes for your project and then you will have a "conflicts" page in the Pull wizard allowing you to use 3rd-party tool to merge changes.

However I'll note once more that we will look into possibilities to add more options and control to the end-users on how the logic of building files should work.

Thank you,

Vladimir

Vladimir, 

Thanks for the reply. Apologies that mine is so late.

Yes, I've tried merging but in most cases I shouldn't need to - and there doesn't seem to be an easy way to do it. For example, today I was working on a new class that ONLY I have worked on. I've only used TWS to modify it. It only exists on my machine and in my sandbox. Nobody else has touched it.

But, at some point I tried to build the file again and TWS says there are server changes pending that are newer and I must download the latest. Well, clearly the latest version is on my machine - not the server. When I click compare I see a 'Diff for <classname>.cls' tab open showing the differences. TWS thinks the changes I've made locally are older than what is on the server, even though I've very recently updated my local files. I shouldn't have to merge this. I should just be able to push my most recent version of this file to the server and build. BUT, if I did decide I needed to merge my local changes with the server version, I don't see any way to easily do that and commit to the server for build. If I use a diffing tool and save my changes locally, TWS still won't let me save to the server until I discard my changes or overwrite them with the older version from the server. I don't see how this makes any sense.

Currently, the only options I have when TWS decides it favors the server version over my local version are 'Compare' and 'Discard'. What if I don't want to discard the work I've done? Because, why would I? Does anyone ever do a bunch of work and then throw it away because the server version is different? Why would anyone ever do that?

I understand that you're committed to this particular workflow but couldn't we just add a button so that the developer can actually commit the code they write to Salesforce without having to jump through a bunch of hoops. At least as a stopgap, adding an overwrite option (see mockup) would make TWS a much more usable product. 

Best Regards

BUT, if I did decide I needed to merge my local changes with the server version, I don't see any way to easily do that and commit to the server for build. If I use a diffing tool and save my changes locally, TWS still won't let me save to the server until I discard my changes or overwrite them with the older version from the server. I don't see how this makes any sense.

Currently, the only options I have when TWS decides it favors the server version over my local version are 'Compare' and 'Discard'. What if I don't want to discard the work I've done? Because, why would I? Does anyone ever do a bunch of work and then throw it away because the server version is different? Why would anyone ever do that?

Hi nebocreek,

I absolutely agree with you that the situation and approach of discarding your changes absolutely does not make any sense - no one likes throwing out results of his work! There is another option in the currently implemented TWS flow which should be used in such cases instead of discarding your changes: using merge tool as a part of the Pull process.

In order to use this approach you should have any of this tools - Araxis Merge, BeyondCompare3, BeyondCompare4, KDiff3 (bundled as an optional component with The Welkin Suite's full installer), WinMerge.

After you will receive an error message on build saying that there is a newer version of the file - please Pull changes for your project and you will see "Conflicts" page in the Pull wizard:

When you press the Resolve button on this page an external merge tool will be launched (If there is no merge tool configured in The Welkin Suite, you can configure it in the Main Menu: Tools ⇒ Options ⇒ External tools). There you will be able to see and resolve all the conflicts. After you complete this on the "Conflicts" page you should get "Resolved" mark next to the file and you can finish the Pull process.

At that point nothing won't be changed on the Salesforce side, however you will locally have a file with both your and remote changes and TWS will be aware that your version is the latest one. 

Final action in this flow is to execute a build again and your changes should be sent to Salesforce without any issues.

However I've added your suggestion to have an option to override remote changes with a local one to our backlog.

Please let me know if using the merge process I've described above helps you.

Thank you,

Vladimir

Hi guys,

I hope you are doing well, and I'm happy to inform you that we implemented the Force Pull and Force Buil functionality for one or several files.

You can find more info on these changes and some additional ones here.

So I'll close the current topic.

If you have any questions, please let us know and we'll be happy to answer all of them.

Have a nice day!

Kindest Regards,

Kate