On Wed, Apr 22, 2009 at 5:13 AM, Tomeu Vizoso <to...@sugarlabs.org> wrote: > On Wed, Apr 22, 2009 at 10:49, Sascha Silbe > <sascha-ml-ui-sugar-de...@silbe.org> wrote: >> On Fri, Apr 17, 2009 at 02:06:55AM +0200, Sascha Silbe wrote: >> >> [Mockups] >>> >>> The second one [2,3] modifies the date field to be a combo box, like >>> shown in Journal Designs #12 [4]. >> >> The fine thing with mockups is that they show just what you imagine, not the >> complicated reality. >> >> How do we actually handle branches? >> >> Option 1: >> * show all versions in the branch of the current entry, including all >> ancestors on "super" branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1, >> 1]) >> * rebuild the date/version box on selection of a version >> + consistency: no matter how you got to the current version, it will always >> look the same >> - oneway: once you select a version on a "super" branch, you're stuck to it >> and can't change back to the originally chosen version anymore. >> >> Option 2: >> * show all versions in the branch of the current entry, including all >> ancestors on "super" branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1, >> 1]) >> * always show the date/version box of the originally selected version >> + oneway: you can go back to the originally selected version from any >> ancestor >> - consistency: depending on where you entered the tree, you'll get access to >> different versions. >> >> Option 3: >> * only show direct linear ancestors, not "super" branches >> + no consistency or oneway issues >> - no access to earlier branches, i.e. any load+save of a non-HEAD version >> will cut the entire ancestry for the just saved version >> >> Option 4: >> * flatten and sort the entire version tree according to the date >> + no consistency or oneway issues >> + access to all branches/versions >> - no information about ancestry, an intermediate version might lack content >> that both "neighbors" (in the list) have >> >> >> Thinking about it, Option 4 is probably the way to go for now (unless >> someone can come up with a smart #5). Rely on the user to tag the documents >> well enough to avoid confusion. We probably want to revise this decision >> later when we got some experience with actual user behaviour. > > #2 doesn't sound too bad to me.
I agree, I think #2 is a good option. I understand the confusion with the inability to show descendants of a given entry, but in practice versioning in Sugar (I expect) will be used more like a history of changes than a full version tree. Merging would complicate this (we can cross that bridge if/when we support it), but until then we always know the full ancestry of a given node as a single ordered path. This history (and not future) of a specific entry is likely of most importance in the context of a Journal which is meant to as a record of the past. One other note on this idea. Technically, we would be able to show *some* "future" (newer) versions for a given entry...we can show all descendants up until a branch unambiguously. I'm not sure which approach (ancestors only, or ancestors plus un-branching descendants) is the better course. Finally, just for fun, let me offer an option 5... Option 5: * show all versions in the branch of the current entry (including all descendants prior to a branch), including all ancestors on "super" branches (i.e. 1.1.3 shows [1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1, 1]) * set apart by a separator line at the top of the version menu, show all n children at the first branch in the tree. + you can get to any point in the tree from any other point + the tree is reduced to a manageable list at every step, which shows ancestor history for the current entry and a single "choice" at the first branch in the tree. - if you navigate to an ancestor, it might not be obvious how to get back to where you started (if there were intermediate branches). - perhaps this exposes too much, making the system more complicated. Food for thought. Eben > Regards, > > Tomeu > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
