On Tue, Jul 26, 2011 at 2:33 PM, Terry Brown terry_n_br...@yahoo.com wrote:
On Tue, 26 Jul 2011 11:58:12 -0700 (PDT)
Edward K. Ream edream...@gmail.com wrote:
I have no interest in complicating the read logic to handle such
special cases: I recommend checking the Leo and Bzr diffs closely
On Jun 22, 10:08 am, Terry Brown terry_n_br...@yahoo.com wrote:
I thought it was [safe] to ignore (i.e. delete without inspection)
recovered nodes nodes, but they just bit me.
I don't believe there is any way, in general, for it ever to be safe
in all situations. Leo would have to read your
On Jun 22, 3:31 pm, Ville Vainio vivai...@gmail.com wrote:
Yeah, this should not happen. Py files should win over txt files by default.
It's conceivable that this could be done safely, but once people start
reverting files it seems there is no *simple* foolproof way to recover
mechanically.
I
On Tue, 26 Jul 2011 11:58:12 -0700 (PDT)
Edward K. Ream edream...@gmail.com wrote:
I have no interest in complicating the read logic to handle such
special cases: I recommend checking the Leo and Bzr diffs closely
whenever there is a surprise. Leo's recovered nodes present the
relevant info
I thought it was save to ignore (i.e. delete without inspection)
recovered nodes nodes, but they just bit me. I usually revert *Ref*.leo
and *.txt when committing changes which should apply only to .py files,
I assume this can generate recovered nodes nodes if clones in the .txt
file get out of
Yeah, this should not happen. Py files should win over txt files by default.
Terry Brown terry_n_br...@yahoo.com wrote:
I thought it was save to ignore (i.e. delete without inspection)
recovered nodes nodes, but they just bit me. I usually revert *Ref*.leo
and *.txt when committing changes