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 ;-).
Thanks!
Ian
More information about the Vm-dev
mailing list