On 08.01.2013 10:05, Bert Huijben wrote: > I don’t think we can keep the moved-to tracking working between > multiple dbs, but I don't think we can just break that you can ‘svn > mv’ data between working copies. > > Maybe it should still work as add+delete in that case, but beaking > scenarios is for 2.0, not for 1.8. > > > We shouldn’t break user scenarios... especially if the only reason is > to keep things easy, to release something fast.
We should break user scenarios if we do it for the right reasons. We already did that once, in 1.7 -- disjoint working copies are a thing of the past. And even earlier we completely changed the .svn/entries format, which broke any number of automated environments. I have nothing against people doing copy + delete between different working copies. But they shouldn't be doing "svn move" as long as we have one database per working copy. (having one db for /all/ working copies would be a different proposition, since we then could do rename tracking properly. But that's not going to happen anytime soon -- if ever). I'll point out that the case where you don't have a common root dir checked out but still want to perform a move is easily solved by in-repository moves. Does it require a change in habits? Sure; but so did 1.7 require that a gazillion scripts stop looking at .svn/entries. > In those cases we should delay the feature to do things properly. Which appears to be never, right? Because someone will always find a weird edge-case that "worked in 1.2 but doesn't in 1.10" which will be argument for delaying progress again. It's the same Neon vs. Serf story all over again. And I have to remind you that if we'd thought in these terms back in 2004, we'd still not have a 1.0 release. You're basically proposing we remove cllient-side rename tracking and all its short- and long-term benefits because some people use Subversion (IMO) strange ways. Something's wrong with that picture. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
