On Mon, Dec 26, 2011 at 1:24 PM, Seth Johnson <[email protected]> wrote: > 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.
Oh: and I guess this means you would lose all the versions. Version history isn't shared in this approach. Hmm, probably: NEVer mind . . . :-) Seth > 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.
