bug in svnx and rollback of /trunk/platforms/Cross/vm/sq.h needed (1172)

Ian Piumarta ian.piumarta at inria.fr
Wed Apr 13 22:14:25 UTC 2005

On Apr 13, 2005, at 15:01, Tim Rowledge wrote:

> So let's just drop the no longer needed macro.

Sorry -- my confusion.  The macro is still in there.  (To support 
non-inlined compilation I undef it in my sqPlatformSpecific.h.  A more 
compatible approach would be to test for SQ_VI_BYTES_PER_WORD defined 
and undef the macro conditionally.  I took it out initially, then put 
it back with the sqPlatSpec undef before comitting.)  The only issue 
remaining is the extra field in keyboard events to send a 32-bit wide 
char value.

The remaining confusion (and roll-back to 32-bit-only code) seems to 
have come from John's implementation of SVN which happily committed a 
stale sq.h against a newer version in the repository.  John fixed this 
and I'm about to commit the 1-liner for keyboard events and then we 
should be up to date again and compiling cleanly in 64-bit mode.

I guess the lesson here is: please (please [please]), before committing 
anything to the trunk, make sure you are not committing a modified 
stale source file against a newer version in the repository.  FWIW 
(this won't fix procedural problems with GUI-based interfaces ;-) 
here's what I do before committing anything (to any repo, anywhere, for 
any project):

   - run 'svn st -u' in the dir I'm committing
   - if any files have '*' before them, they've changed in the repo 
since I last updated
     + move the local version aside (deleting the original name)
     + update just the conflicting file with 'svn update 
originalName.whatever', to get a fresh copy from the repo
     + diff the updated original version against my modified copy
     + copy (or propagated changes from) the new version back into the 
original version
   - svn commit -m 'hopefully without inadvertent roll-back'

If a GUI-based SVN cannot support this kind of caution by immitating 
the 'svn st -u' step then please be extra careful before committing (or 
just open a terminal window and run the status check manually ;-).


More information about the Vm-dev mailing list