On Thu, Sep 16, 2010 at 09:21, Julian Foad julian.f...@wandisco.com wrote:
Greg Stein wrote:
...
Also, please note that I want to expand the presence values
dramatically with this move to NODES. I suggest the following new
values:
Can you explain what these would mean, and what are the main
On Mon, 2010-09-20 at 13:17 -0400, Greg Stein wrote:
On Thu, Sep 16, 2010 at 09:21, Julian Foad julian.f...@wandisco.com wrote:
Greg Stein wrote:
...
Also, please note that I want to expand the presence values
dramatically with this move to NODES. I suggest the following new
values:
On Mon, 2010-09-20 at 18:45 +0100, Julian Foad wrote:
On Mon, 2010-09-20 at 13:17 -0400, Greg Stein wrote:
On Thu, Sep 16, 2010 at 09:21, Julian Foad julian.f...@wandisco.com wrote:
Greg Stein wrote:
...
Also, please note that I want to expand the presence values
dramatically with
On Mon, Sep 20, 2010 at 14:07, Julian Foad julian.f...@wandisco.com wrote:
On Mon, 2010-09-20 at 18:45 +0100, Julian Foad wrote:
...
FULL SET OF VALUES
The values listed above cover most of the cases. Next we must consider
how to get a full set of values to represent all possible changes.
On Mon, Sep 20, 2010 at 15:36, Greg Stein gst...@gmail.com wrote:
...
Erik and I talked further on IRC...
I believe the right approach is a simple boolean prior-deleted,
meaning the nodes visible just under *this* layer have been deleted.
Examining the root node's moved_to column can refine
Greg Stein wrote:
On Wed, Sep 15, 2010 at 13:29, Julian Foad julian.f...@wandisco.com wrote:
Bert, Erik, Greg...
I think the schema should not disallow the 'excluded' presence in NODES
table where op_depth 0 (which corresponds roughly to old
WORKING_NODE). There are already 'copy'
Bert, Erik, Greg...
I think the schema should not disallow the 'excluded' presence in NODES
table where op_depth 0 (which corresponds roughly to old
WORKING_NODE). There are already 'copy' cases where it is used, and
seems useful and right.
I also think the schema should not disallow 'absent'.
7 matches
Mail list logo