Greg Stein writes:
> On Mon, Sep 9, 2013 at 11:29 AM, Julian Foad
> wrote:
>> Philip Martin wrote:
>>> The current Ev2 has atomic add for files and directories, it doesn't
>>> attempt to reuse the alter operations by adding "empty" nodes and then
>>> altering those empty nodes. The current Ev2
On Mon, Sep 9, 2013 at 11:35 AM, Julian Foad wrote:
> Branko Čibej wrote:
>> Julian Foad wrote:
>>> The design of Ev2 is based on the concept of incremental edits to a
>>> "current" tree state. I
Not really. The core/original design was "random access editing". Then
danielsh had a question abou
On Mon, Sep 9, 2013 at 11:29 AM, Julian Foad wrote:
> Philip Martin wrote:
>> The current Ev2 has atomic add for files and directories, it doesn't
>> attempt to reuse the alter operations by adding "empty" nodes and then
>> altering those empty nodes. The current Ev2 also has move and copy
>> ope
Philip Martin wrote:
> The current Ev2 has atomic add for files and directories, it doesn't
> attempt to reuse the alter operations by adding "empty" nodes and then
> altering those empty nodes. The current Ev2 also has move and copy
> operations that do attempt to resuse alter. I'm not clear why
Branko Čibej wrote:
> Julian Foad wrote:
>> The design of Ev2 is based on the concept of incremental edits to a
>> "current" tree state. I feel that the idea that you could start editing the
>> tree, deleting subtrees, and then come to an operation that says "Now please
>> recover one of the s
Julian Foad writes:
> Branko Čibej wrote:
>
>> Can we please stop arguing about API semantics in terms of wc.db
>> implementation details? They bring nothing useful into the discussion.
>> Design the API first, /then/ worry about how to implement it.
>
> While you and I are among those who prefer
On 9 Sep 2013 16:22, "Julian Foad" wrote:
> The design of Ev2 is based on the concept of incremental edits to a
"current" tree state. I feel that the idea that you could start editing
the tree, deleting subtrees, and then come to an operation that says "Now
please recover one of the subtrees tha
Branko Čibej wrote:
> Can we please stop arguing about API semantics in terms of wc.db
> implementation details? They bring nothing useful into the discussion.
> Design the API first, /then/ worry about how to implement it.
While you and I are among those who prefer to discuss the design in terms
Greg Stein wrote:
> On Fri, Sep 6, 2013 at 1:47 PM, Philip Martin wrote:
>> [...] 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(A/B/C@original, A, replace=R)
> move(A/B@original
On Sat, Sep 7, 2013 at 6:30 AM, Branko Čibej wrote:
> On 07.09.2013 12:47, Greg Stein wrote:
>...
>> I'm curious why a move() would be sent to a client.
>
> Off the top of my head:
>
> * It would help find better solutions to a category of tree conflicts
> that we currently do not handle ver
On 07.09.2013 12:47, Greg Stein wrote:
> On Thu, Sep 5, 2013 at 6:51 AM, Branko Čibej wrote:
>> ...
>> For the server->client-mixed-revision
>> scenario, I now believe this is not the case.
> I'm curious why a move() would be sent to a client.
Off the top of my head:
* It would help find bette
On 06.09.2013 18:56, Johan Corveleyn wrote:
> I don't fully grok the Ev2 ideas and discussions, so not sure this is
> relevant, but please do remember this little detail: for working
> copies on case-insensitive filesystems, it's important that deletes
> are executed before adds (for handling case-
On 07.09.2013 11:25, Philip Martin wrote:
> Greg Stein writes:
>
>> On Fri, Sep 6, 2013 at 1:47 PM, Philip Martin
>>> 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?
>
On Thu, Sep 5, 2013 at 6:51 AM, Branko Čibej wrote:
>...
> For the server->client-mixed-revision
> scenario, I now believe this is not the case.
I'm curious why a move() would be sent to a client.
Cheers,
-g
On Sat, Sep 7, 2013 at 5:08 AM, Philip Martin
wrote:
>...
> Note that we have to save the original nodes in the temporary table even
> though we don't yet know that they will be needed. In this case a later
> move is going to refer to original A but we don't know that is going to
> happen. For t
On Sat, Sep 7, 2013 at 4:25 AM, Philip Martin
wrote:
> Greg Stein writes:
>
>> On Fri, Sep 6, 2013 at 1:47 PM, Philip Martin
>>> 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 al
Philip Martin writes:
> Greg Stein writes:
>
>> move(A/B/C@original, A, replace=R)
>
> What does the receiver do? I suppose it could implement the replace and
> move the replaced nodes to some temporary table:
>
> NODES local_relpath revision status repos_path
> A 6
Greg Stein writes:
> On Fri, Sep 6, 2013 at 1:47 PM, Philip Martin
>> 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?
How does you suggestion work? Start with
NODES loca
Greg Stein writes:
> On Fri, Sep 6, 2013 at 10:50 AM, Philip Martin
> 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 peo
On Fri, Sep 6, 2013 at 5:50 PM, Philip Martin
wrote:
> Philip Martin writes:
>
>> What about alter_dir? I think the rule is that alter_dir on a directory
>> should occur before add or delete affects the children of the directory.
>> There is also a rule:
>>
>> * - The ancestor of an added, copi
On Fri, Sep 6, 2013 at 10:50 AM, Philip Martin
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.
>
> move_away A, id=1
> move_
Johan Corveleyn writes:
> I don't fully grok the Ev2 ideas and discussions, so not sure this is
> relevant, but please do remember this little detail: for working
> copies on case-insensitive filesystems, it's important that deletes
> are executed before adds (for handling case-only renames: 'svn
On Fri, Sep 6, 2013 at 1:47 PM, Philip Martin
wrote:
> Greg Stein writes:
>
>> On Fri, Sep 6, 2013 at 10:50 AM, Philip Martin
>> wrote:
>>>...
>>> again either invalid or switched. This implies that if we want to
>>> combine
>>
>> They are already combined. One person is trying to *decombine* th
Philip Martin writes:
> What about alter_dir? I think the rule is that alter_dir on a directory
> should occur before add or delete affects the children of the directory.
> There is also a rule:
>
> * - The ancestor of an added, copied-here, moved-here, or
> * modified node may not be delete
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: vrijdag 6 september 2013 17:50
> To: Greg Stein
> Cc: dev@subversion.apache.org
> Subject: Re: Move using initial state
>
> Philip Martin writes:
>
> > What abou
On Fri, Sep 6, 2013 at 11:36 AM, Branko Čibej wrote:
> On 06.09.2013 17:50, Philip Martin wrote:
>> Philip Martin writes:
>...
>> I've been thinking about alter_dir and I see no reason, in the update
>> editor at least, for a rule that requires alter_dir before adding or
>> removing children. Th
On 06.09.2013 17:50, Philip Martin wrote:
> Philip Martin writes:
>
>> What about alter_dir? I think the rule is that alter_dir on a directory
>> should occur before add or delete affects the children of the directory.
>> There is also a rule:
>>
>> * - The ancestor of an added, copied-here, mov
"Bert Huijben" writes:
> Shouldn't alter_dir get the complete list of directories when children are
> added/removed?
Yes, I didn't mean to imply anything else. If alter_dir is called it
must get a complete list of children. However alter_dir doesn't have to
occur before children are added/delet
Philip Martin writes:
> This implies that if we want to
> combine
>
> 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=
I didn't mea
On 05.09.2013 09:13, Greg Stein wrote:
> On Wed, Sep 4, 2013 at 10:43 AM, Apache subversion Wiki
> wrote:
>> ...
>> Given these constraints, not all combinations of moves can be expressed
>> using a “move source to destination” operation, with or without a “rotate”
>> operation, without using te
Philip Martin wrote:
> Greg Stein writes:
>> [from the Wiki]
>>> Given these constraints, not all combinations of moves can be expressed
>>> using a "move source to destination" operation, with or without a "rotate"
>>> operation, without using temporary paths.
>>
>> I'm not buying that you ne
Greg Stein writes:
> On Wed, Sep 4, 2013 at 10:43 AM, Apache subversion Wiki
> wrote:
>>...
>> Given these constraints, not all combinations of moves can be expressed
>> using a “move source to destination” operation, with or without a “rotate”
>> operation, without using temporary paths.
>
>
32 matches
Mail list logo
