[Sugar-devel] Git Backend Architecture | GSoC'15

[Sam P.]

Hi Shaifali,

I'm a bit late to the conversation, but I'll add my 2c anyway:

1)  Kids are versioning work (eg. write document, turtle blocks projects),
not code.  I think that's what you meant, but please use terminology
"activity instances" or "journal entries"  for documents and "activities"
for apps.

2)  I don't think we should require a sign in initially.  Remember, making
a git repo is as easy as "git init".  I think we can pull the ID data from
the sugar shell (username = committer name...).  Maybe we can only ask for
passwords when they try to push to secured endpoints (github, school
server, friends laptop...)?

3)  Will this be git repo per document or git repo per whole journal?  I
would suggest per document because I would like to be able to share
documents and their attached histories (see point 4)

4)  You haven't really talked about committing.   Making a good UX for
committing is going to be very important - what's the point of git if all
the commits are just made at arbitrary times with messages like "made
changes"?  I think if you make a good UX for commiting, you will take the
journal from a file manager to an actual journal; somewhere where you store
work and log changes (in git).  So here are some UX ideas:

* Have a "Add a change point (commit)" button in the activity metadata
toolbar (the one that lives under the colored activity icon).  When users
click that they get a popup box summarizing the changes and letting them
write a commit message (separated into a body and title).  Like the github
pull request dialog but for committing.

* If the user has made changes, make the stop button into a dropdown
palette.  Instead of clicking it stopping the activity, give them the
option to "stop and mark this change point (commit)" or "stop without
adding change point (commit)".  Choosing the option to commit should bring
up the dialog.

*  In the journal details view, list all the commits like a real life
journal.  Have a text box so the user can make a new commit whenever they
want, even if the commit diff would be completely empty.  This makes each
document feel like it has a journal where the user can write journal
entries to document what they have done with each document.

5)  How are you going to graphically display diffs?  I mean if I add a dot
point to a list in abiword/write, I don't want to see this (real
abiword/write document extract BTW):

+ <p level="1" listid="1014" parentid="0" style="Normal" xid="59"
props="list-delim:%L; list-decimal:NULL; list-style:Bullet List;
start-value:0; margin-left:0.5000in; text-indent:-0.3000in;
text-align:left; field-font:Liberation Sans"><c props="width:0in;
list-tag:1019; font-family:Sans; display:inline; color:000000;
font-weight:normal; text-position:normal; lang:en-AU; font-style:normal;
text-transform:none; font-variant:normal; bgcolor:transparent;
font-size:12pt; homogeneous:1; list-style:Bullet List; height:0in;
text-decoration:none; font-stretch:normal"></c><field type="list_label"
xid="60" props="width:0in; font-family:Sans; display:inline; color:000000;
font-weight:normal; text-position:normal; lang:en-AU; font-style:normal;
text-transform:none; font-variant:normal; text-decoration:none;
bgcolor:transparent; list-style:Bullet List; homogeneous:1; height:0in;
font-size:12pt; font-stretch:normal"></field><c props="width:0in;
font-family:Sans; display:inline; color:000000; font-weight:normal;
text-position:normal; lang:en-AU; font-style:normal; text-transform:none;
font-variant:normal; text-decoration:none; bgcolor:transparent;
list-style:Bullet List; homogeneous:1; height:0in; font-size:12pt;
font-stretch:normal">   Cup measures</c></p>

This project is coming along really well!  Good work so far!

Thanks,
Sam

On Mon, Apr 6, 2015 at 1:38 AM Shaifali Agrawal <agrawalshaifali09 at gmail.com>
wrote:

> Here <http://wiki.sugarlabs.org/go/Gitbackend> I have listed functional
> requirements and put user work flow. Please let me know if any neat is
> needed.
>
> Thanks!!!
> Shaifali Agrawal
> about.me/shaifaliagrawal
>   [image: Shaifali Agrawal on about.me]
>     <http://about.me/shaifaliagrawal>
>
> On Mon, Mar 23, 2015 at 1:25 PM, James Cameron <quozl at laptop.org> wrote:
>
>> Most if not all of the git size increase is caused by the checked out
>> working copy.  That would not happen though.  A backend would use a bare
>> repository.  A working copy of an entry would only exist for the duration
>> of an activity.
>>
>> If it did become a problem, it should be possible to turn off this
>> feature for systems with limited space, like XO-1.  I don't think the XO-1
>> is sufficient reason to avoid git altogether.  We have XO-4 now.  Sugar
>> must move on, and not be held back by an installed base of XO-1.  Let the
>> user decide how to use the space available.
>>
>> If the datastore (which is used to store the journal) were to use the
>> same method as it does now for most entries, then there would be no size
>> increase.
>>
>> Then, the user might select an entry in the journal for which a git
>> backend is to be used.  Once this is done, a history of changes to this
>> entry can be kept.
>>
>> On the other hand, this all seems premature.  Before the implementation
>> details are debated, describe the user work flow.
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150405/a1c2c303/attachment.html>