Re: Move Tracking in the Update Editor

Stefan Fuhrmann wrote: > On Fri, Aug 30, 2013 at 2:02 PM, Julian Foad wrote: >> . > > I read the wiki page and agree that all those issues are real. > > So, here is my take on how to address them. Maybe you > find something usef

Re: Move Tracking in the Update Editor

On Fri, Aug 30, 2013 at 2:02 PM, Julian Foad wrote: > Branko Čibej wrote: > > > On 30.08.2013 13:03, Julian Foad wrote: > >> I'm working on how the update editor can handle moves. It's more > >> complex than the commit editor, because there can be multiple > >> instances of the "same" reposito

Re: Move Tracking in the Update Editor

Julian Foad writes: > Philip Martin wrote: > >> A current Ev1 drive would be: >> >>     delete A >>     open B >>     change_prop B >>     close B > > Right.  Note that here the changes in B are expressed relative to the > pre-existing 'B' base state. > >> For the Ev1+ drive we add move and drop

Re: Move Tracking in the Update Editor

Philip Martin wrote: > Julian Foad writes: >> Philip Martin wrote: >>> There is a related issue with mixed-revision working copies.  Suppose A >>> gets moved to B in some commit.  A mixed-revision working copy could >>> contain both A and B so what does the update that includes that commit >>

Re: Move Tracking in the Update Editor

Julian Foad writes: > Philip Martin wrote: >> There is a related issue with mixed-revision working copies.  Suppose A >> gets moved to B in some commit.  A mixed-revision working copy could >> contain both A and B so what does the update that includes that commit >> do?  I suppose the server stil

Re: Move Tracking in the Update Editor

Philip Martin wrote: > Julian Foad writes: >> Julian Foad wrote: >>> Philip Martin wrote: [...] I can imagine an enhanced Ev1 editor drive that does     move away A     move to C (original A)     del A     move away B     move to C (original B)     del B    

Re: Move Tracking in the Update Editor

Julian Foad writes: > Julian Foad wrote: > >> Philip Martin wrote: >>> [...] I can imagine an enhanced Ev1 editor drive that does >>> >>>    move away A >>>    move to C (original A) >>>    del A >>>    move away B >>>    move to C (original B) >>>    del B >>>    add C >>> >>> The dele

Re: Move Tracking in the Update Editor

Julian Foad wrote: > Philip Martin wrote: >> [...] I can imagine an enhanced Ev1 editor drive that does >> >>    move away A >>    move to C (original A) >>    del A >>    move away B >>    move to C (original B) >>    del B >>    add C >> >> The deletes lead to tree-conflicts on A and B

Re: Move Tracking in the Update Editor

Julian Foad wrote: > Philip Martin wrote: >> [...] I can imagine an enhanced Ev1 editor drive that does >> >>    move away A >>    move to C (original A) >>    del A >>    move away B >>    move to C (original B) >>    del B >>    add C >> >> The deletes lead to tree-conflicts on A and B

Re: Move Tracking in the Update Editor

Philip Martin wrote: >> On 30.08.2013 17:18, Julian Foad wrote: >>> The client *does* need to know that B is in fact being moved to C, so >>> that it can offer to transfer my local modifications from B to C. > > Allowing multiple moves to the same destination doesn't really fit with > Ev2 but I c

Re: Move Tracking in the Update Editor

On 30.08.2013 17:18, Julian Foad wrote: > Branko Čibej wrote: > >> It strikes me that if for update-like edits, which are driven by the >> server, the once rule is interpreted in terms of WC paths, not node URLs >> or node IDs; then the server already has all the information it needs to >> transfor

Re: Move Tracking in the Update Editor

On 30.08.2013 19:12, Julian Foad wrote: > Branko Čibej wrote: > >> One possible solution is to replay the moves in the order they happened. >> Then you'd get two cases: >> >> * A is an ancestor of B: the operation is: > ('Ancestor' meaning a time-line predecessor of the same node-copy-id.) Yes.

Re: Move Tracking in the Update Editor

Branko Čibej wrote: > On 30.08.2013 17:18, Julian Foad wrote: >> Branko Čibej wrote: >>> It strikes me that if for update-like edits, which are driven by the >>> server, the once rule is interpreted in terms of WC paths, not node URLs >>> or node IDs; then the server already has all the inform

Re: Move Tracking in the Update Editor

Branko Čibej writes: > On 30.08.2013 17:18, Julian Foad wrote: >> Branko Čibej wrote: >> >>> It strikes me that if for update-like edits, which are driven by the >>> server, the once rule is interpreted in terms of WC paths, not node URLs >>> or node IDs; then the server already has all the infor

Re: Move Tracking in the Update Editor

Branko Čibej wrote: > It strikes me that if for update-like edits, which are driven by the > server, the once rule is interpreted in terms of WC paths, not node URLs > or node IDs; then the server already has all the information it needs to > transform the working copy. > > Take your first multip

Re: Move Tracking in the Update Editor

On 30.08.2013 13:03, Julian Foad wrote: > I'm working on how the update editor can handle moves. It's more > complex than the commit editor, because there can be multiple > instances of the "same" repository node in the WC, so moves are not > necessarily unique. > > This is a copy of my notes in p

Re: Move Tracking in the Update Editor

Branko Čibej wrote: > On 30.08.2013 13:03, Julian Foad wrote: >> I'm working on how the update editor can handle moves.  It's more >> complex than the commit editor, because there can be multiple >> instances of the "same" repository node in the WC, so moves are not >> necessarily unique. >>

Re: Move Tracking in the Update Editor

On 30.08.2013 13:03, Julian Foad wrote: > I'm working on how the update editor can handle moves. It's more > complex than the commit editor, because there can be multiple > instances of the "same" repository node in the WC, so moves are not > necessarily unique. > > This is a copy of my notes in p