344
edits
Changes
Jump to navigation
Jump to search
Line 26:
Line 26: + + + + + + + + + + + + + + + + + + + +
Talk:Version support for datastore/Proposal (view source)
Revision as of 06:18, 16 April 2009
, 06:18, 16 April 2009finish #sugar excerpts, add link to gnome thread
:<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.