[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 8 Jan 2013 12:30:56 +0100

> -----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.

And we only broke certain very specific scenarios in 1.7. All of them are documented including the entire reasoning in the api errata.

Just breaking things to get things released is something we can do in 2.0.

Moves can work the way they worked, including proper tracking... It is just a lot of work and might not fit a timeframe of a few weeks.

I'm not 100% sure for all the 'svn merge' scenarios, but for update and switch can just work by applying the after update/switch data to the op_depth of the move-target and then (auto-)resolving conflicts where we shadow that layer.

We know what was moved vs what was copies, because we marked the moves as such. (And if we didn't the bug is right there).

WC-NG doesn't store how a working copy was transformed to a state, but just the final state (see design), so moves can be combined once they are single revision. The merge code does this all the time.
(In 1.6 every node merged was added, while in 1.7 we collapse single revision copies)

Received on 2013-01-08 12:31:42 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.