On 11/19/16, Andy Goth wrote:
> One final thing. Richard, I don't have commit access to SQLite since I
> never requested it, but I did sign its contributor agreement at the same
> time as I signed Fossil's agreement. Would you welcome my attempt to
> incorporate your words about the special behavi
Jan, I'm not sure you and Richard concur, or maybe you and I don't concur
on the meaning of the word "concur." ;^)
"A closed branch should be a branch in which all leaves are closed" is not
the definition Richard advocated. If I understand him correctly, he said to
use the "/brlist definition" whi
Op 19 nov. 2016 6:25 p.m. schreef "Richard Hipp":
> On 11/19/16, Andy Goth wrote:
> > Going forward, which definition do we want?
>
> I think the definition used by /brlist.
>
> Reasoning:
> (1) I don't think the difference is all that important. If you have
> multiple branches with the same name,
On 11/19/16, Andy Goth wrote:
> Is this extension documented? What is the precise behavior? Are there
> guarantees that it will be preserved throughout future versions of SQLite?
> When was it introduced?
I thought I had documented this someplace, but now I cannot find
where. In any event, it is
Is this extension documented? What is the precise behavior? Are there
guarantees that it will be preserved throughout future versions of SQLite?
When was it introduced?
Repeating myself so we don't lose focus: I was originally looking at the
inconsistent definition of open/closed branches. Given w
On 11/19/16, Andy Goth wrote:
>
> If I understand correctly, the baseline branch ls query defines a closed
> branch as having no leaves not referenced by closed tags. The baseline
> "new" /brlist query instead checks whether "the" check-in is referenced
> by a closed tag. Which check-in? Hard t
