Open jessesaga opened 2 years ago
This is also an issue for Javascript files. If a step is added to a Transformer in front of a Javascript step, the new filename will be different, e..g. changing from sourceConnector-transformer-step-4.js to sourceConnector-transformer-step-5.js
Similar if the step description is changed and for other cases where the filename is derived from context instead of being fixed.
An option to keep Javascript embedded in the XML would help with part of this, but not for renamed Channels, etc. Having the Javascript files separate by default makes things nice for manual editing thereof. It's NOT so nice for source control. Creating the option would allow the user to choose which is better for their particular use case.
It's easy to work around the current rename limitation recursively removing the mirthSync generated files in the target directory before pulling again. That being said - we do plan to implement a more graceful approach in the near future that doesn't require this workaround for any renames or deletions in channels, javascript files, etc.
In terms of breaking out the javascript .... I prefer it broken out for source control. When it's broken out from the XML things like syntax highlighting work properly when using Github or other such tools/services to view the diffs/pull requests. Same goes for navigating the code in those tools.
I'm willing, though, to add an option to not break out the javacsript of you think that would be useful for your use case. It should be easy to add. I'll go ahead and create an issue to track that.
Thank you. I think the breakout is a double-edged sword. It has the advantage you described, but it would make it more difficult to track the history if it's both changed and renamed in a single commit. Ultimately, I guess it comes down to user preference. The new option would address that.
Currently, mirthSync does not clean up channels, groups, or code templates that have been renamed or deleted. This can be worked around by deleting all files locally and doing another pull but it would be preferable for mirthSync to handle that logic.