GALAHAD: Well, let me have just a little bit of peril?
LAUNCELOT: No, it's unhealthy.
GALAHAD: Bet you're gay!

-- Monty Python and the Holy Grail (1975)

Introduction

I'm sitting here in my apartment amongst boxes and boxes, still unpacked from moving from San Diego. Moving is always a pain and this time is no exception. Packing all your stuff takes some time and unpacking takes even more time since you have to figure out where to place stuff, now in the new place you don't really know where everything goes. Speaking of packing and unpacking (nice dissolve, eh? :) doing the same for your changelists in perforce should be a breeze. The command 'p4 diff' actually outputs some interesting information, amongst them a full description of the differences of the currently checked out files. Unfortunately the output is not trivial to reapply again. Well to the rescue comes two little python scripts!

... and in comes p4diff and p4patch

Running p4diff will produce a file that records all the information about the files that differ from the repository. This single file can then be fed to the program p4patch which will reapply the changes. That's it! The p4patch will sync to the correct version and then overwrite the whole file with the version that was saved off with p4diff. Now I tried for a very brief time to re-implement the patch program in python for unified diffs, but that was just no point to it, when I still have to solve the binary file problem. Both the text files and the binary files are save off as a whole instead of diffs.

Originally before I had the compression the two tools were completely driven by pipes and fit nicely into the whole UNIX paradigm. I dropped the pipe interface though since on windows pipes and python happens to be really broken so it didn't make sense. And it also sidestepped the whole binary/text open modes which are just so sad.

A word of caution

So I'd be a little bit worried if this script encourages you not to check in more often, this is contrary to my belief of frequent and small checkins. This script should really be used for backup purposes and maybe testing on pristine systems to make sure that large patches are working before checkins. They're also not really tested that well, for example I'd be very surprised if they work with paths with spaces in them. But then again, don't have spaces in your repository. It just makes things so much easier.

In closing

This was just a short little excuse to put these scripts online, hopefully someone gets some use out of them. I'm probably going to use them in the future myself if I ever find myself with a large changelist before the weekend and don't really fancy sitting and checking it in at 7pm, but rather go down to the local pub instead and drink this great beer. So there, these scripts are really enablers for beer. And how can that be wrong? Cheers.

Resources

Comments