Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 t
  • 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.)

    • 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:changedtic