This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Upcoming demote in 6.2 vs manual way

Finally got this posted correctly on the Wiki!

During the 6.2 sprint review on 09/24, I mentioned we would share the steps we currently use for a demote operation, in the hope of getting some discussion going around the differences between this way and the new Demote feature scheduled for 6.2. The demo went by pretty quick, and I may not have caught all aspects of this new feature. But I’m afraid it might not be as straightforward and robust as the method posted on the Wiki. I hope I’m wrong.



  • From the 6.2 CLI User's Guide for demote:

    "When you demote an element from a parent stream to a child stream or workspace, the element is removed

    from the default group of the parent stream, and is added to the default group of the child stream. That is,

    the element becomes inactive in the parent stream, and active in the child stream."

    This is not a "demote" at all. If you wanted to demote Mary's promotion but leave Roger's as-is (the version from the promotion he did before Mary's), you would not be able to use this operation, since it would remove Roger's change too. Still, the only way to accomplish a demote of Mary's change is to follow the steps I posted on the Wiki.

    This is very unfortunate.

  • Hi Brian,

    Thanks for the post. Demote is not a replacement of revert.  Ideally, it will be used in a lot of the typical situations where a user wants to "undo" the immediate (last) promote that has happened.  You're right in that if there are dependencies or later promote transactions for the earlier promote you wish to use demote, you will probably need to use revert in those cases. Demote can't be used in every use case, it wasn't designed for that, actually that's what revert is for.  However, revert is too troublesome for the simpler use cases, which is what demote will be targeted for. Have you had a chance to test 6.2 yet?



  • Hi Jimmy,

    I think you misunderstood my point. If the user's intention is to remove all changes made to these elements from the time they first became active in the stream, i.e. his last promotion, all his prior promotions, and the changes made by all of his colleague’s promotions, and retain them in the child stream, then this is the command to use. But I would not call this an undo or demote since it impacts more than just him and his last inadvertent promote operation. In fact, I think it will lead to a lot of support calls and disgruntled users over damage resulting from the use of a command that is mislabeled and hence misunderstood.

    Frankly, I’m not sure how useful this operation will be. It’s easy to know the impact of demoting an individual user’s change but quite another to know (with all interdependencies) the same for everyone’s change.

    I see this as another misnomer like “Revert-to-Backed” (corrected to Revert-to-Basis in 6.x) and envision a future Technical Notes entry to clarify its use. Feel free to include the text from my Wiki post in this note so folks can do what I would call a real demote.

    To be honest, I’m just tired of folks criticizing AccuRev because they don’t understand it. Here, we've just giving them more ammunition.