Solution explorer should have an option to manually refresh the directory structure to check if there are any new changes made in the project directory.
Posted 01 Dec 2017
Thank you for your request.
The Welkin Suite requires additional information from the organization for files in the project, for example - ID, hashsum, modification date, etc. Without this data some of the essential features of the IDE won't be available, this is why the following workflow is not supported by the IDE in the regular projects.
However, if you are working with SalesforceDX projects - this functionality is already present there.
In the meantime, we will try to find a way to allow importing files from your file system into a project directly.
The Welkin Suite
Posted 04 Dec 2017
We need a way to do this since there are chances that a project would be connected to a git repository and the files will change external to TWS whenever changes are pulled from a remote repo to a local repo. This is a pretty generic user case that most of the developers might face.
Could you please let me know if there is a workaround for this since this is really hampering my work as of now.
Posted 2 days ago and edited 2 days ago
Thank you for your response and please sorry for a delay in my answer.
As I've mentioned in the topic on our forum, The Welkin Suite's project file stores a lot of additional information and some of this information is related to a content of files in the project.
This is why the way how The Welkin Suite will allow you to work with Git and how this will work in the best case (of course if not taking into account SalesforceDX) – when you will have the whole TWS project in the Git repository, including the *.sfproj file itself.
In your case, I assume that the project file is not stored as a part of the Git repository or not all team members are using TWS to work with sources in the repository - this causes all of the issues that you've mentioned in your bug reports.
From another point, the suggested best practice solution from Salesforce for your workflow would be to use the SalesforceDX as its exact goal is to simplify the teamwork and collaboration using Git or any other version control system. The Welkin Suite's project type for SalesforceDX strictly follows that pattern and allows you to modify the sources in any way outside of the ide.
Hope this helps.
The Welkin Suite
Thank you for your reply. Here is the problem that I am facing and why the solutions you suggested won't work.
Consider this scenario. I have a team of 2 developers who are working on a packaging org. This org has many components that are included in the final package, while there are many that are not a part of the package and were only created for few proof of concepts. This org is linked to a git repository which only contains the components that are part of the final package (and does not contain any files related to TWS since not all developers use TWS).
Now let's say developer 1 added few new files in the package and modified others. Now there is no way in TWS to retrieve only those files that are a part of a particular namespace/package. This will force the other developer to retrieve everything from the org and clutter his local working directory with components that are not even a part of the package. This is not feasible since the git repository should only contain the components that are a part of the namespace/package.
Also, consider this, developer 1 pushed something to the git repository. Now since this repositry only contains the components that are a part of the package, developer 2 pulls them outside of TWS to get the latest changes from git. This messes up TWS configuration and TWS starts to behave abnormally.
So the solution that I am looking for is either of the one mentioned below:
1) Allow TWS to pull only those components that are a part of a particular namespace/package for a packaging org OR
2) Allow TWS to refresh the files even if they are changed outside of TWS by some external application.
I hope I have made the scenario clear enough for you to consider this feature request on priority since my team is practically stuck here and this is really frustrating.