Re: 'svn mv' between disjoint wc's of disjoint subtrees

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