<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi Shaifali,<br><br></div>I'm a bit late to the conversation, but I'll add my 2c anyway:<br><br></div>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.<br><br></div>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...)?<br><br></div><div>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)<br></div><div><br></div>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:<br><br></div>* 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.<br><br></div>* 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.<br><br></div>* 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.<br><br></div>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):<br><br>+ <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><br><br></div>This project is coming along really well! Good work so far!<br><br></div><div>Thanks,<br></div><div>Sam<br></div></div><br><div class="gmail_quote">On Mon, Apr 6, 2015 at 1:38 AM Shaifali Agrawal <<a href="mailto:agrawalshaifali09@gmail.com">agrawalshaifali09@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="http://wiki.sugarlabs.org/go/Gitbackend" target="_blank">Here</a> I have listed functional requirements and put user work flow. Please let me know if any neat is needed. <br></div><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">Thanks!!!<a href="http://about.me/shaifaliagrawal" style="text-decoration:none" target="_blank"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="height:30px;font-size:0px"></td></tr><tr><td style="line-height:1;padding:0px;vertical-align:top" align="left" valign="top"><div style="margin:0;font-size:18px;line-height:1;font-weight:bold;color:#333333;font-family:proxima-nova-1,Proxima-Nova,Helvetica,Arial,Sans-Serif">Shaifali Agrawal</div> <div style="margin:0;margin-top:3px;font-size:12px;color:#2b82ad;font-family:proxima-nova-1,Proxima-Nova,Helvetica,Arial,Sans-Serif">about.me/shaifaliagrawal</div> </td> </tr> <tr> <td style="line-height:1;vertical-align:top;padding-top:8px" align="left" valign="top"> <div style="text-align:right;background-color:#c5d0e0;min-height:4px"><img src="http://d13pix9kaak6wt.cloudfront.net/signature/colorbar.png" alt="Shaifali Agrawal on about.me" style="float:right;border:0;margin:0;padding:0;display:block" height="4" width="88"></div> </td> </tr> <tr><td style="height:20px;font-size:0px"> </td></tr> </tbody></table> </a> <br></div></div></div> <br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 23, 2015 at 1:25 PM, James Cameron <span dir="ltr"><<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br> <br> 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.<br> <br> 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.<br> <br> 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.<br> <br> On the other hand, this all seems premature. Before the implementation details are debated, describe the user work flow.<br> <div><div><br> _______________________________________________<br> Sugar-devel mailing list<br> <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br> </div></div></blockquote></div><br></div> ______________________________<u></u>_________________<br> Sugar-devel mailing list<br> <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.<u></u>org</a><br> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/<u></u>listinfo/sugar-devel</a><br> </blockquote></div>