Settings and activity
6 results found
-
7 votesWouter shared this idea ·
-
26 votes
On it!
We started the development of this feature. Please keep tuned because we are going to release much more!
Wouter supported this idea · -
87 votesWouter supported this idea ·
-
65 votesWouter supported this idea ·
-
108 votesWouter supported this idea ·
-
15 votes
An error occurred while saving the comment Wouter shared this idea ·
Hi!
There would be a few options how to do this.
The first one would be to add two environment variables:
PLASTIC_INITIAL_CHANGESET: the changeset where the user triggered the update command.
PLASTIC_FINAL_CHANGESET: the changeset the user is at after the update.
While this solution is sufficient, it doesn't allow us to know the path of changesets the user took during the update since some of the changeset numbers inbetween those two might be on different branches.
A second and more complete option would be to have an input in the after-update trigger containing the path of changesets the users followed to get to it's current state.
For branches, I assume this path would either follow the current branch until a merge operation allows the switch to the other branch or either go back to the base of the two branches. This option might be a lot harder to implement though. I also made some assumptions about your update process that may be completely wrong and thus make this an unfeasible option.
A third option would be to add to the current input <{0}:{1}> an extra variable containing the changeset(s?) that the change is coupled to.
I hope this clears things up :)