Le 27 oct. 2010 à 20:08, Niels Grewe a écrit : > On Wed, Oct 27, 2010 at 03:17:19PM +0200, Quentin Mathé wrote: >> I have started reworking the object store API to regroup delta and full >> saves into single unit/store rather than using two object stores. >> I need to finish this code and commit it. Should I finish this asap or is >> this not too critical? >> We can discuss thereworked API and the needs you envision in more details >> if needed… >> I have some other ES API and code cleaning changes still to be committed. >> Let me know if you prefer I commit that asap or later (after you merge your >> recent work into trunk). > > Most of the archiver/unarchiver stuff lives in its own file, with only a > few support changes in ETSerializer.m and ETDeserializer.m, so feel free > to commit your changes whenever you're ready. I don't mind taking time > to adapt my stuff for them.
ok :-) >> Afaik, there is no branch concept in Eric's CoreObject and each version is >> uniquely identified by a SHA. Uniquely identified version makes much easier >> to handle merging. You can freely move around bits of history. For example, >> suppose you copy some history to another core object, makes some more >> changes and then wants to reintegrate it back into the first core object. >> You could also compute which parts of the history can be deleted more easily >> (the job of the garbage collector to be written). >> >> We discussed the matter a bit with Eric last string and I told him I liked >> the ideas and suggested we could keep the same ES API (or not), but decide >> that: >> - a branch is just a convention at the implementation level (a core object >> directory inside another core object directory in the case of an object >> bundle, and a reference to the "parent" version and core object) >> - identify each core object version by a UUID on disk (and cache a version >> number in the metadata db or put both in the archive filename) >> >> My opinion is that branches should probably not exist at the implementation >> level but are a convenient construct at the API and user level. > > So the consensus is that ES should only provide persistency services and > CO is exclusively in charge of tracking object history etc.? Sounds fine > to me. Yes, that's why ES and CO are two distinct frameworks, you can use ES without CO. Projects other than Étoilé might be interested by that. Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
