Mercurial > hg > evolve
changeset 246:1e8e32d3871c
doc: idea about OnDisk Storage
author | Pierre-Yves.David@ens-lyon.org |
---|---|
date | Sat, 12 May 2012 00:12:18 +0200 |
parents | 9ccf8492d5c5 |
children | 1a713fa2d3ba |
files | docs/obs-implementation.rst |
diffstat | 1 files changed, 57 insertions(+), 17 deletions(-) [+] |
line wrap: on
line diff
--- a/docs/obs-implementation.rst +++ b/docs/obs-implementation.rst @@ -11,22 +11,33 @@ What data should be contained in a Marker ? ```````````````````````````````````````````````````` -There is 2 data that **must** be stored +There is two critical data that **must** be stored in an obsolete Marker. :object: the old obsoleted changeset -:subjects: - list of new changeset. **must** accept 0, 1 or 2 element at least. Shall it - accept more than three ? +:replacements: + list of new changeset. list size can be anything, including 0 (0..N) + +Everybody agreed on this point. + + --- This is probably a good idea to have an unique Identifier, for UI, transfert and access. :id: same as changeset but for marker. +The field below will depends of the way we exchange obsolete marker betwenn +changeset. + + --- + Having audit data will be very usefull. When it get messy you need all the -information you can to understand the situation. (could be a group level) +information you can to understand the situation. + +I have the felling that we are versionning history. Therefor we will probably +need the same kind of information than when versionning Files. :date: date of the marker creation @@ -41,26 +52,55 @@ :operation: Kind of rewritting operation that created the marker (delete, update, split, fold, reordering) To help conflict resolution. -Any other data ? +Matt see this a "too complicated". I'll wait for him to meet a very hairy +situation to agree that they are needed. + +Leaving the door open to any addition data is an option too. + +How shall we store Marker on disk +````````````````````````````````````````````````````````` -Shall we store the marker alone or should be group them ? -````````````````````````````````````````````````````````````` +Requirement +............. + +We need to quickly load the 'object' to know the "obsolete" set. +We need quick access by object and replacements to travels along the graph. + +Common Part +............. + +The file is store in `.hg/store/obsmarkers`. It is a binary files: -Several operation rewrite multiple changeset at once. It may make sense to group -marker in this case. +We probably need a Format Version Number somewhere + +I'll put it in `.hg/store/obsmarkers-version` + +Minimalistic proposal +......................... + +The core of a Marker will we stored as: -This could be seen as the same improvement than the introduction of coherent -"changesets" in Files version control. +* number of replacement (8-Bytes integer) +* node id of the obsolete changeset (20-Bytes hash) +* node id of replacement changeset (20-Bytes hash x number of remplacement) -This would help exchange and undo. +Version with ID +......................... + +This version add a node id computed from the marker content. It will be present +*before* other data: + +* node id of the maker (20-Bytes hash) -How shall we store Marker on disk (and in memory) ? -````````````````````````````````````````````````````````` +Version with Metadata proposal +............................... -We need to quickly load the 'object' to know the "obsolete" set. +An extra files is used to old metadata (date, user, etc) `.hg/store/obs-extra`:. The format of this +field is undefined yet. This will add the following field at the end of a marker -We need quick access by object and subject. +* offset of the metadata in obs-extra (8-Bytes integer) + How shall we exchange Marker over the Wire ? `````````````````````````````````````````````````````````