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

Move Tracking in the Update Editor

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 progress. I could use some suggestions or thoughts