Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gracefully handle renames and deletions #26

Open
jessesaga opened this issue Nov 17, 2021 · 4 comments
Open

Gracefully handle renames and deletions #26

jessesaga opened this issue Nov 17, 2021 · 4 comments

Comments

@jessesaga
Copy link
Contributor

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.

@elavy-harris
Copy link

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.

@elavy-harris
Copy link

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.

@jessesaga
Copy link
Contributor Author

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.

@elavy-harris
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants