Skip to content
← Customer Feedback for plasticscm

Settings and activity

6 results found

  1. Go ahead and implement traveling locks

    108 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    9 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    An error occurred while saving the comment
    Wouter commented  · 

    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

    Wouter supported this idea  · 

  2. Make customextensions.conf available from global config

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    Wouter shared this idea  · 

  3. A complete dark theme for windows cloud client

    26 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    3 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    Wouter supported this idea  · 

  4. If a changeset is deleted, switch to the parent changeset and KEEP the changes in the "pending changes"

    87 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    12 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    Wouter supported this idea  · 

  5. Workspace-wide exclusive checkout

    65 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    15 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    Wouter supported this idea  · 

  6. Provide changeset-id's in update triggers

    15 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    2 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    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  ·