Re: Representing Leo outlines in git

2014-07-29 Thread Fidel N
You were right, I was asking about paste-node. The thing is, in the described scenario (the node gnx's that we are going to paste have disappeared from the outline, IE, been cut), the paste-retaining-clones *would behave exactly as paste-node* with the addition that the nodes would have kept

Re: Representing Leo outlines in git

2014-07-24 Thread Fidel N
When you cut an outline, then paste it otherwhere (same or other file), you loose the gnx of every node in that outline. The Paste Node As Clone (paste-retaining-clones) command preserves gnx's, and hence clone links. Edward Shouldn't paste-clone do a paste-retaining-clones by

Re: Representing Leo outlines in git

2014-07-17 Thread Offray Vladimir Luna Cárdenas
Hi, I agree with Jacob. Libgit can be an overkill. I suggested sometime ago using fossil-scm which is sqlite based and kind of a github in a box. For me, the big disadvantage of versioned Leo outlines is its xml format. The org-mode format is a de-facto standard because is just plain text.

Re: Representing Leo outlines in git

2014-07-10 Thread Edward K. Ream
On Wed, Jul 9, 2014 at 4:13 PM, Ville M. Vainio vivai...@gmail.com wrote: I'm always here (reading), just not mustering enough time and energy to write or contribute usefully :). Thanks for reading. I honored. Edward -- You received this message because you are subscribed to the Google

Re: Representing Leo outlines in git

2014-07-10 Thread Zoltan Benedek
Hi, HDF5 is an interesting data format, too (http://www.hdfgroup.org). ensure long-term access to HDF data long term, mission critical data management needs There is a python interface: http://www.h5py.org Regards Zoltan On Tuesday, July 8, 2014 6:43:36 PM UTC+3, Edward K. Ream wrote: On

Re: Representing Leo outlines in git

2014-07-09 Thread Edward K. Ream
On Tue, Jul 8, 2014 at 4:47 PM, Fidel N fidelpe...@gmail.com wrote: When you cut an outline, then paste it otherwhere (same or other file), you loose the gnx of every node in that outline. The Paste Node As Clone (paste-retaining-clones) command preserves gnx's, and hence clone links. Edward

Re: Representing Leo outlines in git

2014-07-09 Thread Fidel N
Wow, wasnt aware of that feature, thanks Edward! On Wed, Jul 9, 2014 at 12:50 PM, Edward K. Ream edream...@gmail.com wrote: On Tue, Jul 8, 2014 at 4:47 PM, Fidel N fidelpe...@gmail.com wrote: When you cut an outline, then paste it otherwhere (same or other file), you loose the gnx of

Re: Representing Leo outlines in git

2014-07-09 Thread Edward K. Ream
On Tuesday, July 8, 2014 2:46:29 PM UTC-5, Ville M. Vainio wrote: Just as a quick stab - I was looking at camlistore through last few days. https://camlistore.org/ It may be more natural fit for Leo outline management than git (as it's more about direct content addressable content access

Re: Representing Leo outlines in git

2014-07-09 Thread Ville M. Vainio
I'm always here (reading), just not mustering enough time and energy to write or contribute usefully :). On Wed, Jul 9, 2014 at 4:13 PM, Edward K. Ream edream...@gmail.com wrote: On Tuesday, July 8, 2014 2:46:29 PM UTC-5, Ville M. Vainio wrote: Just as a quick stab - I was looking at

Representing Leo outlines in git

2014-07-08 Thread Edward K. Ream
I've been studying the pro git book: http://git-scm.com/book and am now closely studying the internals chapter: http://git-scm.com/book/en/Git-Internals Stimulated by Kent's work with db's, the question arises: is it possible to represent a Leo outline as a git object? I believe the answer is

Re: Representing Leo outlines in git

2014-07-08 Thread Fidel N
could that become some short of collaborative outline editing for Leo maybe? On Tue, Jul 8, 2014 at 2:46 PM, Edward K. Ream edream...@gmail.com wrote: I've been studying the pro git book: http://git-scm.com/book and am now closely studying the internals chapter:

Re: Representing Leo outlines in git

2014-07-08 Thread Jacob Peck
What it could allow is per-node versioning... but there are better ways of doing that. Kent's work, for example... --Jake On 7/8/2014 10:16 AM, Fidel N wrote: could that become some short of collaborative outline editing for Leo maybe? On Tue, Jul 8, 2014 at 2:46 PM, Edward K. Ream

Re: Representing Leo outlines in git

2014-07-08 Thread Edward K. Ream
On Tue, Jul 8, 2014 at 9:36 AM, Jacob Peck gatesph...@gmail.com wrote: What it could allow is per-node versioning... but there are better ways of doing that. Kent's work, for example... Thanks, Jake, for this comment. I was wondering about that. I am also interested in preserving gnx's

Re: Representing Leo outlines in git

2014-07-08 Thread Jacob Peck
On 7/8/2014 11:05 AM, Edward K. Ream wrote: On Tue, Jul 8, 2014 at 9:36 AM, Jacob Peck gatesph...@gmail.com wrote: What it could allow is per-node versioning... but there are better ways of doing that. Kent's work, for example... Thanks, Jake, for this comment. I was wondering about that.

Re: Representing Leo outlines in git

2014-07-08 Thread 'Terry Brown' via leo-editor
On Tue, 08 Jul 2014 10:36:43 -0400 Jacob Peck gatesph...@gmail.com wrote: What it could allow is per-node versioning... but there are better ways of doing that. Kent's work, for example... versioning Leo nodes with git 2013-8-28 https://groups.google.com/forum/#!topic/leo-editor/F4k_zCXjtYc

Re: Representing Leo outlines in git

2014-07-08 Thread 'Terry Brown' via leo-editor
On Tue, 08 Jul 2014 11:11:06 -0400 Jacob Peck gatesph...@gmail.com wrote: On 7/8/2014 11:05 AM, Edward K. Ream wrote: On Tue, Jul 8, 2014 at 9:36 AM, Jacob Peck gatesph...@gmail.com wrote: What it could allow is per-node versioning... but there are better ways of doing that. Kent's

Re: Representing Leo outlines in git

2014-07-08 Thread Kent Tenney
and, if the sqlalchemy layer is put between Leo and sqlite, changing ONE string, the db uri, is all that's required to move from sqlite to postgres On Tue, Jul 8, 2014 at 10:19 AM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: On Tue, 08 Jul 2014 11:11:06 -0400 Jacob Peck

Re: Representing Leo outlines in git

2014-07-08 Thread Edward K. Ream
On Tue, Jul 8, 2014 at 10:11 AM, Jacob Peck gatesph...@gmail.com wrote: I'm not well versed in the gnx. I know it's unique per node, but not much else. The gnx is both unique and immutable. It is the permanent, *unchanging* identity of a node. You can't change this behaviour without

Re: Representing Leo outlines in git

2014-07-08 Thread Edward K. Ream
On Tue, Jul 8, 2014 at 10:14 AM, 'Terry Brown' via leo-editor leo-editor@googlegroups.com wrote: On Tue, 08 Jul 2014 10:36:43 -0400 Jacob Peck gatesph...@gmail.com wrote: What it could allow is per-node versioning... but there are better ways of doing that. Kent's work, for example...

Re: Representing Leo outlines in git

2014-07-08 Thread Ville M. Vainio
Just as a quick stab - I was looking at camlistore through last few days. https://camlistore.org/ It may be more natural fit for Leo outline management than git (as it's more about direct content addressable content access than git). I have had sketchy plans of reinventing something like

Re: Representing Leo outlines in git

2014-07-08 Thread Fidel N
About the gnx, I wanted to say something Edward didnt. Not a complaint or anything, but from my point of view, the only feature they are missing: When you cut an outline, then paste it otherwhere (same or other file), you loose the gnx of every node in that outline. That prevents you from using

Re: Representing Leo outlines in git

2014-07-08 Thread 'Terry Brown' via leo-editor
On Tue, 8 Jul 2014 23:47:57 +0200 Fidel N fidelpe...@gmail.com wrote: About the gnx, I wanted to say something Edward didnt. Not a complaint or anything, but from my point of view, the only feature they are missing: When you cut an outline, then paste it otherwhere (same or other Just in

Re: Representing Leo outlines in git

2014-07-08 Thread Fidel N
Hehe yes, we had that conversation before, I wanted to point that out because I felt it is relevant towards recent discussions. There are two answers to the cut/paste solution you suggest. First, i think your solution perfectly makes clear that any node you create will always have its gnx!!