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

Re: Move using initial state

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 06 Sep 2013 19:47:35 +0100

Greg Stein <gstein_at_gmail.com> writes:

> On Fri, Sep 6, 2013 at 10:50 AM, Philip Martin
> <philip.martin_at_wandisco.com> wrote:
>> again either invalid or switched. This implies that if we want to
>> combine
> They are already combined. One person is trying to *decombine* them
> into separate non-atomic unknown-duration actions.

Two people at least. I have shown how Ev2 with a split move could
handle the case

   A/B/C to A
   A/B to A/B
   A to A/B/C

What is your alternative?

>> move_away A, id=1
>> move_here id=1, B
>> into a single
>> move A, B
>> then move and alter need to be combined:
>> move_dir A, B, children=, props=
>> move_file A, B, checksum=, props=
> Well, that is one possibility. But then you also need move_symlink(A,
> B, target=, props=). And if we ever add a fourth node type... another
> entrypoint.

Yes. That's what we do.

> Same issue for copy().
> It was a difficult decision in the Ev2 design.

I suspect copy needs to change as well. If I start with A_at_6 and copy A
to B and modify B then the Ev2 sequence

   copy A B
   alter_dir B properties=n:v
   alter_dir . children=A,B

doesn't work in the update editor. (I could have put "alter_dir ."
earlier, there is no order restriction, but it makes no difference.)

I start with NODES

    path rev status repo
     A 6 normal A

the copy either gives

    path rev status repo
     A 6 normal A
     B 6 normal A

which has B switched, or it gives

    path rev status repo
     A 6 normal A
     B 6 normal B

which has an invalid node B_at_6. Neither of those will update to the
desired final state

    path rev status repo
     A 8 normal A
     B 8 normal B

Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2013-09-06 20:48:14 CEST

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.