Settings and activity
6 results found
-
108 votes
An error occurred while saving the comment 
Wouter
supported this idea
·
-
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
·
-
15 votes
An error occurred while saving the comment Wouter
commented
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 :)
Wouter
shared this idea
·
It's been implemented in the form of 'traveling locks'. The implementation lacks as you can't make branches that never lock stuff and use the old plain merging but is a huge improvement nonetheless