> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: dinsdag 8 januari 2013 10:35
> To: dev_at_subversion.apache.org
> Subject: 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.
It is possible to handle moves the way they worked, while switching from mixed to single revision on the next update.
This works 1000 times better than breaking 'svn mv'.
Users expect conflicts, failures and stuff they should handle on updating and committing, but they don't expect 'svn mv' to fail.
'svn mv' is triggered by all kinds of processes: refactoring, mouse moves, adding new items, etc. etc.
Update and commit are explicit version control actions.
Bert
Received on 2013-01-08 12:25:21 CET