Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 06/11/2020 in all areas

  1. 1 point
    Thanks - that seems like a workflow which would work for my use-case. However, since we are using plastic cloud - I can't use shelving . I'll reapply my changes manually for now. Which can also be a step where code quality can improve, because I'm now recreating/reintroducing the end result while knowing where I am going. But when shelving gets supported for cloud I'll try it out
  2. 1 point
    I shared this request with the team. We already internally commented some improvements about how the user can fine tune the move detections performed by Plastic. It would be a nicefeature but I'm afraid it's not scheduled for the near future. Regards, Carlos.
  3. 1 point
    Although you're past your issue, I figure I might as well mention this for anybody else that comes across this thread looking for a solution in a similar situation: in a scenario where you have hundreds of moves, the least-effort solution is probably to check-in the moves that were correct, then turn off auto-detect and check-in the other ones in a separate changeset. While it might sound messy to have two commits where you could have one, ideally, these moves are being performed on a task-branch, so you would still have a single commit on your main-line. Of course, this is still a work-around. While I can understand from a software architecture perspective why Plastic does not allow you to selectively undo auto-moves (because the auto-moves are transient), it would be much better if Plastic SCM allowed auto-moves to be "staged" (or "locked-in"), just like how you can change items from Private to Added.
×
×
  • Create New...