Re: Moves in FSFS

Stefan Fuhrmann wrote: > Bert Huijben wrote: >> Are you sure there are no behavior changes by changing this? > > Reasonably sure. Previously, it read > >  noderev->copyfrom_path = copy_something(); > >  noderev->copyfrom_path = NULL;  /* result of copy_something() is gone now */ No it didn't. 

Re: Moves in FSFS

On 29.09.2013 19:34, Stefan Fuhrmann wrote: > > On Sat, Sep 28, 2013 at 12:36 PM, Branko Čibej > wrote: > > > Exactly. And this is the second issue of the two I mentioned: in > order to make merge aware of moves, as opposed to copies, you have > to be able to

Re: Moves in FSFS

On 29.09.2013 20:59, Stefan Fuhrmann wrote: > > On Sun, Sep 29, 2013 at 8:46 PM, Bert Huijben > wrote: > > Hi Stefan, > > > > Are you sure there are no behavior changes by changing this? > > > Reasonably sure. Previously, it read > > noderev->

Re: Moves in FSFS

On Sun, Sep 29, 2013 at 8:46 PM, Bert Huijben wrote: > Hi Stefan, > > ** ** > > Are you sure there are no behavior changes by changing this? > Reasonably sure. Previously, it read noderev->copyfrom_path = copy_something(); noderev->copyfrom_path = NULL; /* result of cop

RE: Moves in FSFS

t the actual change itself, to determine if there are possible side effects. Bert From: Stefan Fuhrmann [mailto:stefan.fuhrm...@wandisco.com] Sent: zondag 29 september 2013 18:39 To: Bill Tutt Cc: Branko Čibej; Subversion Development Subject: Re: Moves in FSFS On Sun, S

Re: Moves in FSFS

On Sat, Sep 28, 2013 at 12:36 PM, Branko Čibej wrote: > On 28.09.2013 12:06, Bill Tutt wrote: > > Move tracking can clearly make ones head spin. :) > > Brane: Could Julian and Stephan be asking about how to map between > arbitrary revisions thinking of tree merge scenarios? > > > There are two,

Re: Moves in FSFS

On Sun, Sep 29, 2013 at 2:08 AM, Bill Tutt wrote: > On a slightly different note I noticed this oddity in lib_fs_fs/dag.c from > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/dag.c?annotate=1517479 > > 703 > jpieper849539

Re: Moves in FSFS

On a slightly different note I noticed this oddity in lib_fs_fs/dag.c from http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/dag.c?annotate=1517479 703jpieper849539if (is_parent_c

Re: Moves in FSFS

On 28.09.2013 12:06, Bill Tutt wrote: > Move tracking can clearly make ones head spin. :) > > Brane: Could Julian and Stephan be asking about how to map between > arbitrary revisions thinking of tree merge scenarios? There are two, somewhat related issues. The first involves understanding what act

Re: Moves in FSFS

Move tracking can clearly make ones head spin. :) Brane: Could Julian and Stephan be asking about how to map between arbitrary revisions thinking of tree merge scenarios? That's what always gave me heart burn with the current Noderev behavior and envisioning real moves in Subversion. In thinking

Re: Moves in FSFS

On 19.09.2013 16:46, Stefan Fuhrmann wrote: > Storing Moves > - > > From the FS POV, moves behave like simple ADD/DEL pairs > and should, therefore, be stored as such. Agreed, as far as the changes list is concerned. You have to leave a "tombstone" on the source of a move, so that code

Re: Moves in FSFS

On 19.09.2013 15:58, Julian Foad wrote: > The key point here is that there needs to be a *unique* solution for where > branch/B@20 has been moved to in r40. With copies, of course, there is not a > unique solution when we follow history forward because there can be multiple > copies, but follow

Re: Moves in FSFS

Hi all, I spend most of this week thinking about moves and I changed my mind as further evidence came up. What I fully agree with is: http://wiki.apache.org/subversion/MoveDev/MoveDev#Move_Semantics Then, I found an equivalent expression for the nodeLineID concept central to the move semant

Re: Moves in FSFS

Branko Čibej wrote: > On 19.09.2013 12:09, Julian Foad wrote: >> Branko Čibej wrote: >>> On 17.09.2013 12:55, Julian Foad wrote: branch the trunk:     r20:       trunk         /A         /B       branch         /A (pointer to /trunk/A)         /B (pointer to /

Re: Moves in FSFS

On 19.09.2013 12:09, Julian Foad wrote: > Branko Čibej wrote: >> On 17.09.2013 12:55, Julian Foad wrote: >> [...] >>> Start with >>> >>>r10: >>> trunk >>>/A >>>/B >>> >>> branch the trunk: >>> >>>r20: >>> trunk >>>/A >>>/B >>> branch >>>

Re: Moves in FSFS

Branko Čibej wrote: > On 17.09.2013 12:55, Julian Foad wrote: > [...] >> Start with >> >>    r10: >>      trunk >>        /A >>        /B >> >> branch the trunk: >> >>    r20: >>      trunk >>        /A >>        /B >>      branch >>        /A (pointer to /trunk/A) >>        /B (pointer to /trun

Re: Moves in FSFS

On 17.09.2013 12:55, Julian Foad wrote: [...] > Start with > > r10: > trunk > /A > /B > > branch the trunk: > > r20: > trunk > /A > /B > branch > /A (pointer to /trunk/A) > /B (pointer to /trunk/B) > > modify branch/A: > > r30: > trunk >

Re: Moves in FSFS

On Wed, Sep 18, 2013 at 1:05 PM, Stefan Fuhrmann < stefan.fuhrm...@wandisco.com> wrote: > On Fri, Sep 13, 2013 at 12:41 PM, Branko Čibej wrote: > >> On 13.09.2013 11:32, Philip Martin wrote: >> > Branko Čibej writes: >> > >> >> That said, I still do not understand why a different ID would be nee

Re: Moves in FSFS

On Fri, Sep 13, 2013 at 12:41 PM, Branko Čibej wrote: > On 13.09.2013 11:32, Philip Martin wrote: > > Branko Čibej writes: > > > >> That said, I still do not understand why a different ID would be needed > >> before the copy-on-write happens. Is it because the client doesn't have > >> the full h

Re: Moves in FSFS

On 18.09.2013 10:50, Branko Čibej wrote: > Given all of the above, we're talking about the following algorithm for > move of src to tgt (I'm ignoring parent change, for clarity): > > if src is lazy: > make-mutable(src) > else: > make-mutable(dirname(src)) > modify-dir-li

Re: Moves in FSFS

Julian Foad wrote: > Branko Čibej wrote: >> On 17.09.2013 13:12, Julian Foad wrote: >>> But why does "move" need to create a new node-revision of the moved >>> node [...]?  Why shouldn't it just create a new reference [...]? >> >> Becasue otherwise you can't tell there was a move without comparin

Re: Moves in FSFS

On 17.09.2013 13:43, Julian Foad wrote: > Branko Čibej wrote: >> Note that in the current FS implementation, there is not "node" object >> as such; there are only node-revision records, and the concept of a >> "node" is extrapolated from the node-id, just as a branch is >> extrapolated from the cop

Re: Moves in FSFS

Branko Čibej wrote: > On 17.09.2013 13:12, Julian Foad wrote: >>  But why does "move" need to create a new node-revision of the >> moved node itself (assuming the node isn't lazy-copied and isn't about >> to be modified).  Why shouldn't it just create a new reference to the >> existing old node-

Re: Moves in FSFS

On 17.09.2013 13:12, Julian Foad wrote: > Branko Čibej wrote: >> On 17.09.2013 12:46, Philip Martin wrote: >>> I still don't understand. For a change like a text edit we always call >>> make-mutable and it always gives a new id, either changing the >>> revision-id or the copy-id. It's not c

Re: Moves in FSFS

Branko Čibej wrote: > On 17.09.2013 12:46, Philip Martin wrote: >>  I still don't understand.  For a change like a text edit we always call >>  make-mutable and it always gives a new id, either changing the >>  revision-id or the copy-id.  It's not clear to me that there should be >>  a make-mutab

Re: Moves in FSFS

On 17.09.2013 12:46, Philip Martin wrote: > Branko Čibej writes: > >> On 13.09.2013 11:32, Philip Martin wrote: >>> Branko Čibej writes: >>> >>> There is another aspect to the lazy-copy which is when does the new >>> copy-id get assigned to the lazy children. If we commit >>> >>>move A/f A/g

Re: Moves in FSFS

>> Branko Čibej writes: >>> That said, I still do not understand why a different ID would be needed >>> before the copy-on-write happens. Is it because the client doesn't have >>> the full history available? [...] Hi Brane. Ref.

Re: Moves in FSFS

Branko Čibej writes: > On 13.09.2013 11:32, Philip Martin wrote: >> Branko Čibej writes: >> >> There is another aspect to the lazy-copy which is when does the new >> copy-id get assigned to the lazy children. If we commit >> >>move A/f A/g >> >> then move does not allocate a new copy-id and

Re: Moves in FSFS

On 13.09.2013 11:32, Philip Martin wrote: > Branko Čibej writes: > >> That said, I still do not understand why a different ID would be needed >> before the copy-on-write happens. Is it because the client doesn't have >> the full history available? If that's the case, I suggest we explore >> this o

Re: Moves in FSFS

Branko Čibej writes: > That said, I still do not understand why a different ID would be needed > before the copy-on-write happens. Is it because the client doesn't have > the full history available? If that's the case, I suggest we explore > this on a case-by-case basis, including determining how

Re: Moves in FSFS

On 12.09.2013 12:14, Julian Foad wrote: > Branko Čibej wrote: >> On 11.09.2013 17:21, Julian Foad wrote: >>> One issue that may be harder than it sounds at first is the concept of >>> 'node-line-id' rather than (node-id, copy-id) as the basis of the >>> definition. The point is that when we copy (

Re: Moves in FSFS

Branko Čibej wrote: > On 11.09.2013 17:21, Julian Foad wrote: >> One issue that may be harder than it sounds at first is the concept of >> 'node-line-id' rather than (node-id, copy-id) as the basis of the >> definition.  The point is that when we copy (ordinary copy, not move) >> a directory, we la

Re: Moves in FSFS

On 11.09.2013 17:21, Julian Foad wrote: > One issue that may be harder than it sounds at first is the concept of > 'node-line-id' rather than (node-id, copy-id) as the basis of the > definition. The point is that when we copy (ordinary copy, not move) > a directory, we lazy-copy the children, No

Re: Moves in FSFS

Thanks, Stefan!  Very interesting thoughts.  Especially... (scroll down)... Stefan Fuhrmann wrote: On Wed, Sep 11, 2013 at 5:21 PM, Julian Foad wrote: >>    http://wiki.apache.org/subversion/MoveDev/MoveDev#Move_Semantics >>    http://wiki.apache.org/subversion/MoveDev/MovesInFSFS >> [...] >> >>

Re: Moves in FSFS

On Wed, Sep 11, 2013 at 5:21 PM, Julian Foad wrote: > While discussions continue about the "editor" and the WC side of move > tracking, I'd like to make some progress on the Repository side. > > The Wiki page > > http://wiki.apache.org/subversion/MoveDev/MoveDev#Move_Semantics > > declares the

Re: Moves in FSFS

On 11.09.2013 20:09, Julian Foad wrote: >> Proposal: Resurrect keeping the old node-line IDs, iff >> (a) the copy source (or a parent) got deleted in the next revision >> (b) no copies of that node (or any parent) were added since the source rev. >> That should keep normal copying relativel