[svlug] Preventing a Revision Control Flamewar

[Brian J. Tarricone]

Rick Moen wrote:
> Quoting N.J. Thomas (thomas at zaph.org):
> 
>> As someone else in this thread pointed out, svn does file renames while
>> preserving history just fine -- and this has always been the case (i.e.
>> there has never been a time when "svn mv" did not preserve revision
>> history).
> 
> The point -- as very clearly stated -- was not that there's anything
> wrong with "svn mv", but rather that _rename_ loses history.

How do you define a 'rename' as separate from 'svn mv', then?  If I 'svn 
mv' a file, I retain the history from before and after the move.  Full 
stop.  That's all I care about.  If you're worried about certain 
(infrequent?) merging operations, then sure, you might have a problem. 
But your original assertion (re-quoted here) is half-false:

> svn also cannot handle file renames at all: Instead, you get delete
 > and re-checkin, such that the new file loses the old file's history.

I think we can safely ignore the distinction between your "delete and 
re-checkin" vs. the reality of "copy+delete" and give you that one, but 
the new file does NOT lose the old file's history, as you originally stated.

> You and Brian now officially owe me a refund of the time I wasted
> re-finding this among other things:

*laughs*  The time was yours to waste.

>  http://subversion.tigris.org/issues/show_bug.cgi?id=898
>  Summary: implement true renames

Yes, I found that too yesterday.  How is it relevant to whether or not a 
'svn mv' causes file history to be lost?  Because, well... it doesn't.

> And indeed, needing to implement "svn move" as a copy and delete (and thus
> not as an atomic operation) is pretty ugly design.

So what?  We're talking about functionality here, not design.  If you 
originally stated "svn implements rename through via an ugly method," I 
would've agreed with you.  But you didn't.  You stated something that 
was false.

>  As is this (for MS-Windows users) from
> http://tortoisesvn.net/docs/nightly/TortoiseSVN_hr/tsvn-dug-rename.html:
> 
>   Fortunately there are (at least) two possible methods to rename a file without
>   losing its log history. It is important to rename it within subversion.
>   Just renaming in the explorer will corrupt your working copy!
> 
>   Solution A) (recommended)
> 
>   1. Commit the changes in your working copy.
> 
>   2. Rename the file from UPPERcase to upperCASE directly in the repository
>    using the repository browser.
> 
>    Update your working copy.
> 
>    Solution B)
> 
>    1. Rename from UPPERcase to UPPERcase_ with the rename command in the
>    TortoiseSVN submenu.
> 
>    2. Commit the changes.
> 
>    3.  Rename from UPPERcase_ to upperCASE.
> 
>    Commit the changes.

How is this relevant to the "svn does not preserve history across 
renames" issue?  This issue only affects people on Windows who want to 
change the case of a filename.  And I'd argue that the TortoiseSVN 
authors should have implemented a workaround to ease the pain for their 
users (that is, notice that the user is doing a case-only rename, and do 
the "Solution A" in the background automatically).  Sure, it's an 
unfortunate unexpected side-effect of poor design, but the workaround 
isn't hard to implement.

	-brian