I've shown several developers mini-demos of Perforce (we moving to it in less than a month) and one of the most common questions is "How do I back out a change once its submitted?" We must have people who make a lot of mistakes :-)

I've read tech note 14 on backing out a change list. I wondering if anyone has written a tool based on the third scenario in the technote that would allow a developer to just invoke the tool with the changelist to be backed out as a parameter. The result of the tool would be a changelist ready to be submitted that backs out the change (This would allow the developer to preview whats going to happen and take the blame off the tool for problems it might cause :-)

The tech note procedure seems a little lacking in some respects. For instance, if I do an Add in a changelist which is later backed out, The TN14 process will result in deleting the file, even if there are intervening changes that have occurred. I'd like something automated, but a little less heavy handed. In the example, it would look at the filelog history and see intervening activity. It's ok if the tool defers to the developer on situations it shouldn't make assumptions on.

I'm thinking the tool would create a temporary client, who's view includes only those files affected by the changelist to be backed out-- this makes the sync's in the process isolated from whatever might be going on in the users client and also relatively fast.

The tool could also add a note to the original changelist's description to indicate it was backed out.

Finally, the tool would assure the new changelist (to affect the back out) is attached to the same job(s) that the original changelist was attached to.

John Vriezen vriezenj at lakeviewtech.com