Here is one approach to using sqlite with git. https://ongardie.net/blog/sqlite-in-git/
Chris On Sat, Jul 8, 2017 at 2:16 AM, Xavier G. Domingo <[email protected]> wrote: > From Offray: > > as I understand Sqlite storate will be used only for settings > > and from Terry: > > I don't think we've considered the impact of switching to a binary format > > *That's an important point that was not so clear until now! *At least not > for me considering that Vitalije said the following at the very first post > of this thread: > > >> > > *If we use sqlite as file format for outline data it is trivial to keep > the collected settings in the same file. *And added this later: > * >> *Yes, we are discussing dropping Leo's XML format. > > From Offray: > > 2) import/export from/to .leo XML files, which solves the DVCS integration > issue, > > > Well, that's another important point that *was not so clear **as it is > now in previous posts. *So there is there a wide field to explore... > > Sqlite over XML have proved better response time in loading and querying > when two representation of the same data are available > > That's sure true for querying, but I'm not so sure for loading. > > early optimization is the root of evil, as Knuth said and this is more > like a lot of bump that a big hole ;-). > > I agree in that early optimization is bad, but here *I'm not talking > about optimization at all* so I don't understand the quote. I'm talking > about proper *design *that takes into account the future evolution of the > product. > > The idea is to pass from native Objects representation to files and then > use Git to represent changes in the system. The machinery behind this could > be used with other DVCS, but the focus is now on Git: > https://github.com/pharo-vcs/iceberg/ > > Thanks. Quite interesting, i'll take a look. I've already found > interesting what the project states at its intro (emphasis mine): > > >> Right now we support only git, but Iceberg *is designed* to allow > other code versioning systems in the future. > > That is: it was *designed *from the begining with that multi-VCS support > in mind. That's what I was trying to transmit when I was talking about the > abstraction layers: one can make a proper design from advance to account > for the future expansion of the system to support any VCS. Design is not > "early optimization", is it? > > STON is the storage format you use to "export" notebooks from the image (a > snapshot of all objects in your Pharo system) to the file disk, so they can > be shared and versioned as usual files > > Thanks, I got it. > > The diff is provided by fossil over any text file, as usual with other > DVCS, so is the combination of STON + Fossil that gives you such pretty and > readable output. > > From vitalije: > > There is no need to add db file to git. External files are kept in git. If > you want any part of Leo outline to be kept in git, you can make it > external file and add to git. > > Aha, I see. So now I realise that *I was wrong in one assumption I was > making about Fossil*: that Fossil could handle *naturally* the Sqlite > file versioning just because it is Sqlite-based! > That's why I told that "*using Sqlite as the next Leo file format **is > forcing us to take those files out of git, or to use Fossil** as VCS.*" > Oh my God, I don't know how could I make such a wrong over-simplification > of the problem! Now I see: Fossil is not going to solve the versioning of > Sqlite files more or less than any other VCS does. > > *I'm REALLY sorry for the confusion that such statement may have caused!* > > From vitalije: > > It is not the case that using sqlite as file format or even using fossil > for keeping history of every node in outline is forcing any change in VCS > used for project as whole. > > Now I see. Thanks. Then that reinforces my idea that we should make Leo's > capable of integrating with any VCS. > > Thanks for the warning. > > Je, je, you are welcome! Let me be clear about this point also: my warning *is > not* that we must end the journey just because there is a hole in the > road! It's just that we all have to be aware of the hole and decide the > best way to circumvent it. It seems that you already know how to do it, but > I'm just not sure yet. > > To state it clearly again: the hole is that no VCS is capable of > efficiently handling (storing) a database "as is". > > Let's see the options we have. > > From Terry: > > Sqlite is certainly an option - if you're just using it for settings, it may > not be necessary to include those files in VCS. > > That's an option. The other option, suggested by Offray and Vitalije is to > just always export the Sqlite info to a textual format (which may be XML or > another more-diff friendly format al suggested by them) and have that > included in your VCS. I have yet to think in how would that workflow be for > the settings in Leo because you still want to store the (equivalent to the > now) *leoSettings.leo* file in GitHub... it's an advanced topic for me at > this moment. > > To create more room for confusion :-} there's also now discussion of more > dynamic *code* reloading. I'm unclear as to whether this is for Leo only, in > which case it seems primarily a benefit to Leo developers, or if it would > cover other code being developed in Leo. Without any standard way of doing > the latter, I'm not sure how that would work. > > Cheers -Terry > > and Offray: > > For me there is a deeper question in Vitalije's search and is "How can > improve Leo liveness and responsiveness". > > That's *a bigger and really **exciting endeavour *that I like alot!! To > be clear on that point from my part: I'm *all about liveness* when > programming! That's why I gave Light Table <http://lighttable.com/> a try > in the past, before coming to Leo. It has *liveness of your Python code* > (the one that you are developing) included in its design!... or it may > have, because I could never make it work for me. :-( So I switched to > Leo... with the eye put in a wider interactive programming experience! And > I do still have this purpose in mind for Leo. > > Light Table design was profoundly inspired by Bret Victor ideas which > resonate alot with my own vision of programming. > > There's a lot of work to be done in that direction, but I think *It's > worth any amount of effort*, as Edward likes to say! > > From Edward: > > I prefer exploration to "requirements", but discussions alternatives > forms an important background to exploration. > > I really think we should try to make kind of a roadmap for our > explorations. When you know where you are and you know where you wanna go, > you sketch a roadmap. But that *does not mean that later on, when you are > on the road, you must stick to it at any cost*.* Of course not!* We will > have to adapt to the problems and surprises we'll find along the road and > change the roadmap accordingly at every stage. At least, that's my vision > of software development. Roadmaps are just a tool. They must not get you > out of your Goals. Some prefer to call this difference *Tacticts vs > Strategy*, but I've found that those concepts are quite confusing for > many people, so I choose not to use them. > > Thanks to all for you refreshing ideas! This journey with you all is being > a pleasure... and this is just the beginning! ;-) > Yours, Xavier > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
