Revert before update - why?
Answered
TeamCity svn has a Revert before update option.
However, as documented, even when the option is unchecked, TeamCity still does revert after update.
Revert "before" would mitigate possible merge conflicts before update, but revert "after" will solve those conflicts after update. So as far as I see, the end result should be the same either way.
Is there any particular reason / use case to prefer revert "before" vs. "after" update?
Please sign in to leave a comment.
Hello Joonas,
If option is disabled, then only modifications detected during the update process are reverted. However there are also can be modifications during the build process.
If option is enabled, then all modifications performed during build process will also be reverted. It can be used instead of "Clean checkout" option if you need to revert only versioned files.
Thanks for clarification,
I think the documentation is a bit misleading, or there's something wrong. Let's look at logs.
Revert before update on - then it seems to revert after updating sources - or maybe the log order doesn't reflect the actual order in which things happen?
Revert before update off:
There is no "Reverting local changes for working directory" anywhere in the log. It's not reverting changes at any point. I know that this particular build does some modifications in the versioned code so those should be reverted according to documentation in https://confluence.jetbrains.com/display/TCD10/Subversion#Subversion-Checkoutonagentsettings
In any case, keeping the option on does right thing (updates&reverts, or reverts&updates, before starting the build), and that should be default IMO.
Hi Joonas,
"Revert before update" is correctly described in the documentation. In the first log the changes are reverted before checkout. The line "Checkout from svn+ssh://blah" shows the checkout path, however the checkout process itself is performed after the revert. The log can be a bit confusing.
If "Revert before update" is disabled, then only local modifications detected during the update process (not during the build) are reverted.
Ok, then it's just the log that's not quite clear about in which order things happen. Thanks!