My New CVS vim Functions

Ovid on 2007-04-19T11:34:21

I get tired of reading commit messages in email, only to find out that I forgot to review my commit and I did more than I thought. The following should help out with that. As usual, comments about my awful vim code welcome (the strange bindings are due to finger memory).

noremap ,cd :call SourceReview()   " cvs diff
noremap ,cc :call SourceCommit()   " cvs commit

let g:source_reviewed = "no"
function! SourceReview()
    :!cvs diff % | less
    let g:source_reviewed = "yes"
endfunction

function! SourceCommit()
    if g:source_reviewed == "yes"
        let g:source_reviewed = "no"
        :!EDITOR=/home/cpoe/bin/vim/bin/vim cvs commit %
    else
        echohl WarningMsg
        echo "You cannot commit source code until you review it"
        echohl None
    endif
endfunction

Next I want to figure out how to block committing code unless I've run the tests first, but my tests are open in a separate terminal window. Thoughts?

Testing / Committing Ideas

fansipans on 2007-04-19T14:46:28

As far as testing code before committing ... two ideas:

1. File Timestamps: Have the Teardown method or a special final test put a timestamp in a file (say, .last_tested). Configure your versioning software to check for the existence of this file, and if it exists, look for any source code with a more recent modification time. This might be a pain, as it will show the tests as expired if you update POD, or something else that changes a source file's mtime.

2. File Hash: Create a simple perl/shell script that accepts a single directory as an argument, and looks at all files below that directory matching a certain pattern ("*.pm", "*.pl","*.t", etc.), running a hash (for example, /usr/bin/md5sum) over them, and then producing a final hash for all those hashes, printing it to standard out. Have this script run as your last test, and have it store the ultra-mega-mega hash in a file, checked in the same manner as #1 above by your versioning system.

They're both the same really, just one looks at the actual file's contents. The hash version seems more robust to me though, because you could, for example, filter each source file to remove all comments before calculating the hash, to test code only. Or run it through PPI and remove all POD ;). Also, the hash version can be run to compare files on two separate servers, if your versioning system worked entirely on another server. I'm sure there are many more ways to make it more robust... :)

Counting Ticks

Smylers on 2007-04-20T09:14:49

Vim has a buffer-local variable b:changedtick which counts the number of changes made in that buffer.

So instead of the review setting a boolean flag, it could record the current ticks. Then you could making committing only work if the tick count hasn't increased since then.

(Possibly you need to allow a small increase if reviewing or saving or whatever uses up some ticks.)

Re:Counting Ticks

Ovid on 2007-04-20T09:31:56

Thanks. That solved the problem I discovered with my first attempt. All I had to do was review the code once and hours later, after many changes, I could still commit without a review. The b:changedtick ensures that I can't commit unless I review after every change.

noremap ,cd :call SourceReview()<cr> " cvs diff noremap ,cc :call SourceCommit()<cr> " cvs commit let g:last_tick = 0 function! SourceReview() :!cvs diff % | less let g:last_tick = b:changedtick endfunction function! SourceCommit() if g:last_tick == b:changedtick :!EDITOR=/home/cpoe/bin/vim/bin/vim cvs commit % let g:last_tick = b:changedtick else echohl WarningMsg echo "You cannot commit source code until you review it" echohl None endif endfunction