Functional and UI spec for local moves

[Julian Foad <ju...@btopenworld.com>]

Ben and I recently started producing a functional and UI spec for local moves:

<https://wiki.apache.org/subversion/LocalMoves>


We need this in order to test the sub-features against a known goal, and we need it in order to produce software that has consistency.

Please join in with the thinking and writing.

There's quite a big conceptual change to be addressed, because now that we have local moves we can no longer assume that every path refers to "a node" and that every node has "a path"; now some nodes live at two paths in the WC (at one path "now" and at another path "before").  After trying to decide what various subcommands should do when given the path of one side of the move, and seeing that we have no consistent plan there yet, I wrote in the Wiki: "We need to go beyond simple path-based addressing now that we have 
'move', because it affects two paths so we can't continue to assume a 
model where a path simply addresses 'the node' and a node has 'a path'. 
 Idea: 'to' path identifies the move; 'from' path identifies any 
replacement at that path???"

- Julian


--
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download

Re: Functional and UI spec for local moves

[Thomas Åkesson <th...@akesson.cc>]

On 17 jan 2013, at 20:59, Julian Foad <ju...@btopenworld.com> wrote:

> Ben and I recently started producing a functional and UI spec for local moves:
> 
> <https://wiki.apache.org/subversion/LocalMoves>

I think the table in the wiki provides a well needed overview. If nothing else, it demonstrates the the amount of points of interaction with other commands. 

I don't have the knowledge to comment on some things, but I have a lot of interest in seeing move materialise. There was nothing in the wiki page that I have any issues with. 

> Idea: 'to' path identifies the move; 'from' path identifies any 
> replacement at that path???"

That makes a lot of sense, especially considering replace. Also, it somehow feels consistent with how copy works today (the to-path is key). That should not be a constraint, but still important for end user adoption/understanding. 

Regarding revert and --force:

Yes, I think --force should be required to break the move into copy/delete. It would otherwise become one of those incredibly annoying mistakes. 

- If both to-path and from-path are included on svn revert, perform revert of the whole move. No force required. 
- If from-path has been replaced, the move can not be reverted. The replace must be reverted before (i.e. reverse order to how they were moved). 
- If either from-path or (exclusive) to-path is included, require force to break move into copy/delete. 

Most of this was just rephrasing of the wiki, except the suggestion to revert the move if both sides are included in the command. 

Good stuff,
Thomas Å. 

Re: Functional and UI spec for local moves

[Stefan Sperling <st...@elego.de>]

On Thu, Jan 17, 2013 at 10:58:16PM +0000, Julian Foad wrote:
>  Maybe experiment to document how trunk actually
> behaves at the moment, and review that for any show-stopper issues?

Yes, please! In my opinion this is what we need to do to get 1.8
into shape for release. The more eyes we get on the local moves
tracking feature, the better :)

(BTW I'm very glad that several people seem to have started to
take a serious look at this feature lately!)

Re: Functional and UI spec for local moves

[Julian Foad <ju...@btopenworld.com>]

C. Michael Pilato wrote:

> On 01/17/2013 02:59 PM, Julian Foad wrote:
>>  Ben and I recently started producing a functional and UI spec for local
>>  moves:
>> 
>>  <https://wiki.apache.org/subversion/LocalMoves>
>> 
>>  We need this in order to test the sub-features against a known goal, and
>>  we need it in order to produce software that has consistency.
>> 
>>  Please join in with the thinking and writing.
[...]
> 
> [...] in the interest of sheer practicality, I'd like to step back and ask a
> tangentially related metaquestion:
> 
>     Should we be further delaying Subversion 1.8 for this work?

No, we shouldn't be further delaying 1.8 in my opinion.  I started with the aim of documenting and reviewing how we want 1.8 to behave, but I approached that question by thinking how I'd want local moves to behave, which is a more open-ended question.  We need to do that design but we don't need to do it before branching 1.8.

We can put that aside for now if a different approach would be quicker.  Ideas?  Maybe experiment to document how trunk actually behaves at the moment, and review that for any show-stopper issues?

- Julian

Re: Functional and UI spec for local moves

["C. Michael Pilato" <cm...@collab.net>]

On 01/17/2013 02:59 PM, Julian Foad wrote:
> Ben and I recently started producing a functional and UI spec for local
> moves:
> 
> <https://wiki.apache.org/subversion/LocalMoves>
> 
> We need this in order to test the sub-features against a known goal, and
> we need it in order to produce software that has consistency.
> 
> Please join in with the thinking and writing.
> 
> There's quite a big conceptual change to be addressed, because now that
> we have local moves we can no longer assume that every path refers to "a
> node" and that every node has "a path"; now some nodes live at two paths
> in the WC (at one path "now" and at another path "before").  After trying
> to decide what various subcommands should do when given the path of one
> side of the move, and seeing that we have no consistent plan there yet, I
> wrote in the Wiki: "We need to go beyond simple path-based addressing now
> that we have 'move', because it affects two paths so we can't continue to
> assume a model where a path simply addresses 'the node' and a node has 'a
> path'. Idea: 'to' path identifies the move; 'from' path identifies any 
> replacement at that path???"
> 
> - Julian

Obviously, working against a well-defined goal is wise.  And I suspect that
there are plenty of us devs around willing to help think though what that
goal should be.  Certainly the move problem isn't new, nor has it only
affected just a few of us over the years. :-)

But in the interest of sheer practicality, I'd like to step back and ask a
tangentially related metaquestion:

    Should we be further delaying Subversion 1.8 for this work?

What started back in, what, November or so (?) as what was believed to be
about a month's effort has continued for 2+ months and still seems to be
growing in scope without bounds.  Now, granted, its precisely "bounds" that
you're trying to get out of this exercise -- and again, thumbs up on doing
so, how can I help, etc. -- but this is and has been for a little bit now
pretty much the only bit of coding of any reasonable degree of complexity
that remains on the critical path for an already prolonged release.

I propose that this work be deferred until 1.9 if it looks to drag on for
more months still.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development