Add ability to remote strip changesets

Issue #147 resolved
Former user created an issue

I think this is well described just by the title, but basically:

The ability to strip changesets from a remote repository (especially a private remote repository), just like running hg strip locally.

Comments (10)

  1. Ron Winacott

    If you do implement this feature, please, please, please! make it a configuration item to turn it off! This is a really bad idea, even in private repositories. Once a ChangeSet is in the wild, it is in the wild! If you strip the ChangeSet/Group, and someone that had pulled it before stripping, pushes it right back in to the remote (most likely central) repository. Not good practice in any DSCM system. Striping in your local repository before pushing the ChangeSet in to the wild, is the only safe way you can change history.


  2. Marcin Kuzminski repo owner
    • changed status to open

    Definitely yes, this is also why i still didn't implemented that. I don't want rhodecode to even allow any destructive actions.

    I'm still thinking if this will ever implemented. I you need to strip ask admin to do it on server or whatever, this is a really destructive operation. TBD

  3. Johannes Rudolph

    I agree that you should make dangerous operations explicit.

    However, there is a strong case for allowing this if you use RhodeCode as a means of publishing repositories for individual developers. I am currently working on a project where we have a central repository to which only reviewed changes get pushed. All developers have a fork of this repository where they publish their changes for review.

    It's rare, but it happens that changes get rejected entirely. Sometimes developers accidentally push incomplete changes from their local repos too. In this case, it would be convenient to allow stripping these changesets from the server. Backing these things out just doesn't feel right.

  4. Marcin Kuzminski repo owner

    Agree that proposed workflow could benefit from stripping. I think backout is better solution even if it don't feel quite ok. Next release of rhodecode will have extended code-review that assign a status to each changeset. I as for example manager would like to know that fork's changeset got "rejected" and see the reason for that rejection. For future evaluation. Then i can re-approve the changeset seeing it's being backed-out+fixed. But this is my personal opinion.

    BUT your case is strong enough for to add this functionality to rhodecode. If this will be globaly disabled, and needs a server flag to enable, i feel safe about having it.

  5. Log in to comment