[Sugar-devel] Git Backend Architecture | GSoC'15
martin.abente.lahaye at gmail.com
Fri Mar 20 10:53:14 EDT 2015
For some reason I have not received the original email, not even as spam,
so I can't the original architecture discussion. Thanks Gonzalo for CC'ing.
On Fri, Mar 20, 2015 at 11:22 AM, Gonzalo Odiard <godiard at sugarlabs.org>
> I think the big files issue is a problem with _really_ big files. Not with
> the files
> our users will create and modify.
> My only concern with this project is keep it really simple for our users.
+1, its really important to provide a basic set of functionalities and a
high-level API to access then.
> The objective of have a git backend is have a versioned
> Journal, where you can store all the intermediate steps for a entry.
Yes, but at least for this project we should reduce the scope to one
activity. We mentioned Turtle Blocks because it made sense.
> Other than that, does not have too much sense complicate the interaction
> with the user.
The user should see even higher level options to operate ie., CRUD
operations and versioning options, from the UI.
> The other win would be have a automatic backup in the cloud,
> but then we need identity, like in the plugins.
> On Fri, Mar 20, 2015 at 10:55 AM, Sebastian Silva <
> sebastian at fuentelibre.org> wrote:
>> About this Git as Journal backend project...
>> I have come to the conclusion that it's a terrible idea.
>> Don't get me wrong, I'm the first to recognize git's contribution for the
>> In fact I even have a small git front project
>> However, as a general datastore, git is terribly innefficient especially
>> when dealing with larger or binary files. You can read a detailed account
>> of it's problems in the following article I found really interesting:
>> Unorthodocs: Abandon your DVCS and Return to Sanity
>> It we do insist in adding some sort of version control, then I suggest we
>> look into VCS extensions for large files, and some way that will allow the
>> user to actually erase a file.
>> In the Git world, git-annex does this but it's in my humble opinion
>> A better option for this would be Mercurial's Largefiles extension.
>> Mercurial also has native compatibility with Git, so I tend to think it
>> could be the best of both world.
>> The tricky part here of course is the UI so I would love to see some
>> mockups of what it's expected to look like.
>> El 20/03/15 a las 07:54, Gonzalo Odiard escibió:
>> You can find useful a experiment done by Martin Abente a time
>> ago "FakeCloud: a silly and quick attempt to define a generic structure for
>> web-service-basedJournal storage"
>> sugar branch: https://github.com/tchx84/sugar/tree/fakecloud
>> sugar-fakecloud extension: https://github.com/tchx84/sugar-fakecloud
>> He can provide more information. (cced)
>> On Thu, Mar 19, 2015 at 4:33 PM, Shaifali Agrawal <
>> agrawalshaifali09 at gmail.com> wrote:
>>> On Thu, Mar 19, 2015 at 6:29 PM, Shaifali Agrawal <
>>> agrawalshaifali09 at gmail.com> wrote:
>>>> For the first part I did sturdy research, I have wrote create, read,
>>>> update, delete functions in shell script to work as git based backend. But
>>>> be achieved via libraries like libgit2 js-git. Under the hod git is a
>>>> key-value store and for generating key(sha or hash-objects) it generates a
>>>> checksum of the content of file plus a header. So this can be achieved in
>>>> Links to above mentioned libraries : libgit2
>>> <https://libgit2.github.com/>, js-git
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>> Gonzalo Odiard
>> SugarLabs - Software for children learning
>> Sugar-devel mailing listSugar-devel at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
> Gonzalo Odiard
> SugarLabs - Software for children learning
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel