Friday, January 23, 2009

Simple perforce checkout in emacs using elisp

I know there are all kinds of clever perforce modes, but I prefer to have a few common perforce actions that I write myself and can easily extend and customise as needed.

For example this is all you need to checkout a file you are visiting.


(defun p4-checkout-buffer()
"Check out the current buffer from perforce using a shell command line"
(interactive)
(shell-command (format "p4.exe edit %s" (buffer-file-name)))
(toggle-read-only -1))

Monday, January 12, 2009

Finding writable files in a directory in a windows command line

Simple thing, but if you want to find which files in a directory are writable, use this dos command ...


dir /a-r-d /s /b


/a is to search for attributes. In this case r is read only and d is directory. The minus signs negate those attributes. So we're looking for writable files only.

/s means recurse subdirectories

/b means bare format. Path and filename only.

Thursday, January 8, 2009

Who changed the line your working on last?

My team use Perforce for version control, and I recently wrote an implementation of 'blame', also known as 'praise'. When editing a file that is in Perforce, I can run p4-blame, and it will figure out the last change list that this file, and the line that point is on, was changed. It then opens a buffer containing that change list. This is often useful while working, and is so fast when accessed from the editor, it makes it trivial to do.

First, I wanted it to open two buffers, one with the annotated file (the file you're working on with the change list number at the start of each line), and another with the changelist you're interested in. When running the command multiple times I want these buffers to be deleted. So I added a helper function that creates a named buffer, and if it exists already, makes sure it is empty.


(defun get-buffer-create-and-clear(name)
(interactive "sName: ")
(let ((buffer (get-buffer-create name)))
(goto-line 1 buffer)
(erase-buffer)
buffer))


Ok now for the blame code. As you can see, mostly what it's doing is called the P4 command line and passing the output to buffers. Firstly I call annotate to get the change list numbered lines. Then I go to that file and go to the same line that point was at. (number-at-point) returns that number. Finally I call p4 describe to get the changelist information.


(defun p4-blame()
"blame the current line of code... it seeks out the change list of the last person
to change this line. The arguments to annotate, which dumps the source file with the
change list number it was last altered in, are q (no header) i (follow branches) and
c for change numbers rather than revision numbers."
(interactive)
(let* ((line (line-number-at-pos))
(source-file (buffer-file-name))
(annotate-buffer (get-buffer-create-and-clear "*p4-annotate*")))
(shell-command (format "p4.exe annotate -q -i -c %s" source-file) annotate-buffer)
(goto-line line annotate-buffer)
(let ((change-number (number-at-point)))
(if change-number
(let ((blame-buffer (get-buffer-create-and-clear "*p4-blame*")))
(shell-command (format "p4.exe describe %d" change-number) blame-buffer))
(message "error: could not get change list number for line %d" line)))))



The error detection is a bit sloppy here. I don't know how to figure out if the shell-command failed. But it's not a big deal because if you do this in a file that is not in P4 then it will simply print a message saying could not get change list.

Ideally I could send the error output to a buffer, and then parse it to see if it's empty.