I just stumbled upon this interesting commit message in a git-svn tree I made out of /<trunk|branches/*>/Invasion_from_the_Unknown at Wesnoth-UMC-Dev:

commit def6408717c794e7ac23702978c313e68ed127b4
Author: shikadilord <shikadilord@87cc232e-6748-0410-ac04-a3fa75566414>
Date:   Wed Jan 14 02:31:05 2009 +0000

    Thanks to my awesome time-traveling powers, there are macros in mainline since 1.3.10 or so, wrapping up the [debug_message] tag so I do not need to worry about 1.5.6-1.5.8 compatibility with IftU after the [debug_message] deprecation in 1.5.7+svn.
    
    
    git-svn-id: https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/Invasion_from_the_Unknown@3299 87cc232e-6748-0410-ac04-a3fa75566414

Apparently that is not the only thing my other self from the future did. I found the following in a #wesnoth-umc-dev log of 2009-01-13:

23:27 <Shadow_Master> hey, this is nice!
23:27 <Shadow_Master> look, in the future I was gonna have so many problems with the deprecation of [debug_message] and  my intention to keep IftU compatible with 1.5.6...
23:28 <Shadow_Master> that I sent myself to the past to put some macros into mainline in 1.3.x (Yes, 1.3.x)
23:28  * Shadow_Master now wonders if having done that in 1.3.x will break the space-time continuum

During my work on the Coordinated Wesnoth User-Made Content Development Project (which we dub "wesnoth-umc-dev" for short), I came up with an interesting concept related to Subversion's standard workflow. Half-assed commits are revision commits to the Subversion repository that are not completed due to the subversion client (or server!) process dying unexpectedly, usually due to anything but a SIGTERM.

The obvious symptom of a half-assed commit in your local file system is a bunch of 'L' flags in the 'svn st' command output. These can be removed with svn cleanup. So, most half-assed commits are harmless to you. However, according to the (holy) Subversion Book, it may leave garbage, half-assed transactions in the repository. These are not viewable to anyone but the repository admin of course, and should not harm anyone provided the filesystem on which it resides does not run out of space.

Last afternoon I ran into a more harmful and painful sort of half-assed commit. I renamed some files in my working copy, invoked 'svn ci', and my crappy Wireless LAN connection burped just when it was about to update the working copy with the changes introduced to the repository:

Transmitting file data ...svn: Commit failed (details follow):
svn: MERGE request failed on '/svnroot/wesnoth-umc-dev/trunk/Invasion_from_the_Unknown'
svn: MERGE of '/svnroot/wesnoth-umc-dev/trunk/Invasion_from_the_Unknown': Could not read status line: Connection reset by peer
(https://wesnoth-umc-dev.svn.sourceforge.net)
svn: Your commit message was left in a temporary file:
svn:    '/home/shadowm/src/wesnoth-umc-dev/trunk/Invasion_from_the_Unknown/svn-commit.2.tmp'

Unsurprisingly, I was left with my files in an awful state that caused local conflicts with the repository. That is, next 'svn update' failed because the commit above was successful for the server, leaving the renamed files in the repository. SVN just didn't like that at my end, because I had those renamed files already in the working copy as result of the 'svn move' result I just (half-ass) commited.

Thanks for nothing SVN! Seriously, the protocol should have the server request for a final confirmation from the client to check-in the transaction after its changes have been merged in the client's working copy. Or the inverse: have the client react in a smarter fashion to these situations that people like me often run into. People like me being people who can't afford their own Internet.