Settings and activity

  1. 23 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Wouter supported this idea  · 
  2. 82 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Wouter supported this idea  · 
  3. 59 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    14 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Wouter supported this idea  · 
  4. 42 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Wouter supported this idea  · 
  5. 15 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    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  ·