Talk:Version support for datastore/Proposal: Difference between revisions
Sascha silbe (talk | contribs) add some IRC notes |
Sascha silbe (talk | contribs) finish #sugar excerpts, add link to gnome thread |
||
| Line 26: | Line 26: | ||
:<nowiki>[</nowiki>xdelta for binary diffs] | :<nowiki>[</nowiki>xdelta for binary diffs] | ||
:<nowiki>[</nowiki>in-place execution of activities from datastore] | :<nowiki>[</nowiki>in-place execution of activities from datastore] | ||
:"Running an activity" is a special system-level action available on objects of type "Activity". It specifically means "Executing the code in activity object X with a null input". The other action is "Open with {some activity}". | |||
:another possibility is to ignore branches, and have each leaf ("head") simply show all of its ancestors as a list. | |||
:The Actions view shows "a temporal view of what I did", and the Objects view shows "what I have". | |||
;tomeu: | ;tomeu: | ||
:<nowiki>[</nowiki>opportunistic hardlinking using mtime+checksum] | :<nowiki>[</nowiki>opportunistic hardlinking using mtime+checksum] | ||
:all activities should be able to read all journal instances written by past versions, but we cannot expect it will be that way | |||
;silbe: | ;silbe: | ||
:<nowiki>[</nowiki>filenames are just metadata] | :<nowiki>[</nowiki>filenames are just metadata] | ||
:what about resuming old entries then? does it "run" the activity version it was created in? | |||
:we could filter "temporally near" versions in the default view. | |||
:instead of / in addition to the version tree view, we could have a filter that shows only the "related" (i.e. member of same version tree) documents in the regular Journal view | |||
:<nowiki>[</nowiki>actions view out of scope] | |||
;homunq: | ;homunq: | ||
:<nowiki>[</nowiki>evaluate bazaar etc. as backend] -- SS: potential conflict with XIP - though git might be fine | :<nowiki>[</nowiki>evaluate bazaar etc. as backend] -- SS: potential conflict with XIP - though git might be fine | ||
:<nowiki>[</nowiki>run activities directly from zip file] | |||
:In the main journal list, you can have old versions in the palette, much like the new resume-by-default behaviour in current home view. In journal details, I guess you could have "previous" and "next" buttons as the simple first pass, I'd like a list of versions even better. | |||
:I'd argue that showing separate versions separately in journal list will never be the right thing. I'd rather have ALL old versions totally invisible in journal list (only accessible through "prev/next version" buttons in detail view) than have anything. | |||
:<nowiki>[</nowiki>in response to current Journal being temporal view, so intermediate versions should be there] OK, but they should be grouped, and collapsed by default, to show just head | |||
:I think the simplest, usable prototype would be what I said: just head in list, prev/next buttons in details. | |||
:for now, I'd accept tags as either by-version or global, but mutable and not versioned themselves | |||
:it's really a question of UIs and workflows, and having the prototype will help us actually test some workflows and get a more-informed conversation | |||
=== Gnome work === | |||
[http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00004.html first part] and | |||
[http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00005.html second part] of Roadmap mail. | |||