In this approach you could continue to do collaboration using the external files, while just storing in the db while you go about editing the file with node-level granularity, including going through versions.
But for those who are concerned with collaborating, the minimalist first implementation would either mean everyone uses @shadow files to reconcile their work outside the database, or use a separate vcs at the same time. That is, let multiple users store their own instances of the same complete Leo file in the database, regardless of their lack of consistency -- and then have a separate commit process using external files by someone with the appropriate level of rights, who would store an additional *authoritative* instance in the database. Those working with the database would then have to access that version. As far as I understand external files, I think this means the authoritative version would be created either using @shadow files, or a separate vcs. Either all collaborators would have to provide @shadow files and *not* use another vcs; or all users of the database would be required to provide their external files to a separate vcs. This would be clunky, but 1) only clunky for people who want to do this node-level versioning; and 2) it would be one person doing the authoritative "reconciliation." Seth On Mon, Dec 26, 2011 at 12:15 PM, Kent Tenney <[email protected]> wrote: > The entry point I envision is this: > The gui shows 3 buttons: > <=, ||, => > > If the node which currently has focus, only the double bars are active, > clicking that button puts the current node in the repository. > > if the node is edited, the double bar and the left arrow become active: > clicking <= reverts the node and makes the right arrow active > > || puts current version into the repository > > rinse and repeat. > > The backend would be some sort of db, a versioning system would make > it pretty simple. There could be any number of ways to define the node state. > > I don't see @auto files as exceptional, other than the gnx changing. > > In my workflow, an @auto node is either a > - class declaration > - method definition > - var declaration > - chunk of doc > > In each case, I'd like to have access to versions of the node. > > If this were implemented, I think experience would dictate what metatada > was important/useful to store for a node. > > And, my interest is not in Leo files which multiple people edit at once, > that's > for source code, and a solved problem. I consider my Leo files a reflection of > a personal proclivities in viewing data. > > Thanks, > Kent > - > > > On Mon, Dec 26, 2011 at 10:26 AM, Seth Johnson <[email protected]> > wrote: >> On Mon, Dec 26, 2011 at 11:19 AM, Seth Johnson <[email protected]> >> wrote: >>> On Mon, Dec 26, 2011 at 7:44 AM, Edward K. Ream <[email protected]> wrote: >>>> >>>> I think that's ok. Leo is not going to change in any "big" way unless >>>> the way forward is so simple and compelling that it will be impossible >>>> to forget: like "webs are outlines in disguise." So far, nothing >>>> remotely that simple has appeared. >>> >>> >>> One very simple thing that can be done very easily would be to just >>> store the Leo data as it is, with no thought of distribution or >>> collaboration "within the database implementation" -- then you just >>> store .leo files in the database, produce the external files as you >>> currently do, and collaborate with the external files the way you do >>> now. That would create a database backend that could be extended >>> gradually. As long as it is done in a way that's basically "the same >>> as" a .leo file, any more fundamental reengineering for distribution >>> and collaboration would be no more complex than converting from the >>> model of the Leo file would be in the first place. And in the >>> meantime, people might bang on the backend in interesting ways while >>> keeping its compatibility with the Leo app and its file format. If >>> people show ways of doing distribution and collaboration that way, you >>> can ponder those without worrying about impact on standard Leo. >> >> >> Distribution and collaboration *and versioning* -- I forget! >> >> It might be good to start without versioning and all the state stuff, >> just do without any added features, and then look at different ways to >> do the versioning based on having a "classic Leo" database >> implementation in place. Apparently versioning is a key rationale for >> going to the database, but maybe you can move forward by just setting >> a gold standard for classic Leo first. >> >>> Seth >> >> -- >> You received this message because you are subscribed to the Google Groups >> "leo-editor" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/leo-editor?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/leo-editor?hl=en. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
