Re: Representing Leo outlines in git

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 their

Re: Representing Leo outlines in git

On Thu, Jul 24, 2014 at 8:33 AM, Fidel N wrote: > Shouldn't paste-clone do a paste-retaining-clones by default when no more > nodes with same gnx are in the outline? Leo has no paste-clone command. I assume you are asking about the paste-node command. Imo, the answer should be "no". paste-nod

Re: Representing Leo outlines in git

> > > 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

Re: Representing Leo outlines in git

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. Ha

Re: Representing Leo outlines in git

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: > >

Re: Representing Leo outlines in git

On Wed, Jul 9, 2014 at 4:13 PM, Ville M. Vainio 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 Groups "leo-editor"

Re: Representing Leo outlines in git

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 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 camlistore throug

Re: Representing Leo outlines in git

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

Re: Representing Leo outlines in git

Wow, wasnt aware of that feature, thanks Edward! On Wed, Jul 9, 2014 at 12:50 PM, Edward K. Ream wrote: > On Tue, Jul 8, 2014 at 4:47 PM, Fidel N 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

Re: Representing Leo outlines in git

On Tue, Jul 8, 2014 at 4:47 PM, Fidel N 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 -- You received t

Re: Representing Leo outlines in git

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!! Th

Re: Representing Leo outlines in git

On Tue, 8 Jul 2014 23:47:57 +0200 Fidel N 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 case anyone else

Re: Representing Leo outlines in git

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 gn

Re: Representing Leo outlines in git

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 camlisto

Re: Representing Leo outlines in git

On Tue, Jul 8, 2014 at 10:14 AM, 'Terry Brown' via leo-editor wrote: > On Tue, 08 Jul 2014 10:36:43 -0400 > Jacob Peck 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 >

Re: Representing Leo outlines in git

On Tue, Jul 8, 2014 at 10:11 AM, Jacob Peck 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 breaking clones. Each gn

Re: Representing Leo outlines in git

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 wrote: > On Tue, 08 Jul 2014 11:11:06 -0400 > Jacob Peck wrote: > >> >> On 7/8/2014 11

Re: Representing Leo outlines in git

On Tue, 08 Jul 2014 11:11:06 -0400 Jacob Peck wrote: > > On 7/8/2014 11:05 AM, Edward K. Ream wrote: > > On Tue, Jul 8, 2014 at 9:36 AM, Jacob Peck > > wrote: > >> What it could allow is per-node versioning... but there are better > >> ways of doing that. Kent's work, for example... > > Thanks

Re: Representing Leo outlines in git

On Tue, 08 Jul 2014 10:36:43 -0400 Jacob Peck 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 "Versioning Leo n

Re: Representing Leo outlines in git

On 7/8/2014 11:05 AM, Edward K. Ream wrote: On Tue, Jul 8, 2014 at 9:36 AM, Jacob Peck 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

Re: Representing Leo outlines in git

On Tue, Jul 8, 2014 at 9:36 AM, Jacob Peck 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 somehow, by tracking cha

Re: Representing Leo outlines in git

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

could that become some short of collaborative outline editing for Leo maybe? On Tue, Jul 8, 2014 at 2:46 PM, Edward K. Ream wrote: > 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 > > S

Representing Leo outlines in git

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