June 9, 2015

Living la Vida Helix: Submitting Without Fear

Media & Entertainment

One of the common complaints I hear about centralized version control systems is that they are scary. With every commit being immediately visible there is a feeling that you may screw up everything for your co-workers. What’s worse is that you generally don’t have the power to clean up after yourself. How many of us have had to sheepishly go ask the admin to obliterate something?

With P4D (which we now call Helix Versioning Engine) becoming a proper DVCS, you now can manipulate history that has not yet been shared with other people. Than means you can commit to your heart’s content, and then sweep through later to keep just the interesting commits. It also means that if you accidentally submit something you can deal with it.

Just recently while doing some cleanup work in the Workshop I had just one of these cases. I’d like to walk you through what happened so that you can see how unsubmit and resubmit will help you.

Setting the scene

A user had reported that a number of files that I had added the day before had all of their line endings mangled. The files were already in the shared server, so I didn’t want to run p4 unsubmit there, and anyway I feel it is important for my failures to remain on display for all to see.

So I got to work updating the files.

 p4 fetch

Everyting was up-to-date. Next to find the files with the bad line endings.

grep -lIUr --color "^R"

I was lucky and it was just a handful of files. Thankfully turning Windows line endings into Unixones is a piece of cake with P4D.

p4 client -o | sed s/LineEnd: local/LineEnd: share | p4 client -i

Now to get the files synced with the correct line endings and submitted:

p4 sync -f 
p4 submit -d "Fixing up some busted line endings that snuck in"

All was well and good until I realized that in my excitement I’d mangled some solution files which probably wanted those '\R’s. Thankfully I hadn’t pushed, so I could quickly clean up my mess.

p4 changes -m1
p4 unsubmit @12345

I identified my last change number, and then unsubmitted it. At this point I had all of my changed files in a shelf. In this case I had only one changelist, but I still decided to use p4 resubmit to apply the change. p4 resubmit makes it easy to reapply the changes in order.

p4 resubmit

This kicks me into interactive mode. Because there is a lot you can do with resubmit and I always forget the options, I hit '?' to see the list.

Specify next action ( l/m/e/c/r/R/s/d/b/v/V/a/q ) or ? for help: ?
The following actions are available:
c Modify the change description for this change
m Merge this change, then submit if no conflicts
e Merge this change, then exit for further editing
r Interactively resolve this change, then
submit if no conflicts
a Add (squash) this change into the next unsubmitted
s Skip this change and move on to the next
d Delete this change without submitting it
b Begin again from the earliest remaining change
l List the changes remaining to be processed
v View the current change in short form
V View the current change with full diffs
R Display the status of resolved and unresolved merges
q Quit the resubmit operation<
? Display this help.

In this case I wanted to resubmit all of the files except the solution files, so I selected e

That merged my change back in, but then dropped me back to the command prompt so I could further mangle the files. A quick revert got rid of the changed solution files, and then I used p4 resubmit -Re to resume the resubmit process.

p4 revert ....sln
p4 resubmit -Re

P4D submitted the change again, and cleaned up the shelf for me since I no longer needed it. With that tidied up I was ready to push and share my changes with the community.

p4 push

Sharing that broken change wouldn’t have been the end of the world, but I felt so much more in control being able to clean up those .sln files before pushing out my change. Ever wish you could undo a merge between branches? With p4 unsubmit you can. Helix Versioning Engine gives you a way to safely experiment, modifying history as need be to make sure the changes your coworkers see are the ones you want them to see.

Interested in trying it yourself? You’re just a download of our Helix Versioning Engine and p4 init away from being able to try this all yourself. If you’d like to push to a shared server the Workshop has been running 2015.1 since beta, and Helix Cloud is also using it. As always we’re here to help, so if you have questions, just shout!