Print

Print


On 15 Apr 2011, at 19:32, Ali Asad Lotia wrote:

> It can be handled, but not in a particularly space efficient manner. Neither Git nor Subversion for that matter lend themselves particularly well to storing binary files suc, they are better suited to storing software source code which is text and the standard set of tools available with both are primarily designed for comparing, merging and branching text.

A fair amount of education content is text with the odd diagram. Something which stripped out the extraneous formatting might be a feature.

> The lovely tools for file comparison that you see are specific to Github and would require some sort of image viewing or manipulation tools on your local machine.

Or for images you can use something like Canvas:

http://techcrunch.com/2011/01/31/4chan-founder-unleases-canvas-networks/

> --
> aal
> 
> On Apr 15, 2011, at 4:54 PM, Alex Lydiate wrote:
> 
>> I can see the goodness in this idea, for sure, though I don't know enough about Git to know how viable it is.
>> 
>> Another difference in code and content is potential weight - if I've got four hours of high definition video as part of my 'Seabirds in Flight' OER, can that be handled? 
>> 
>> 
>> 
>> On 15/04/11 16:27, Greg DeKoenigsberg wrote:
>>> 
>>> 
>>> On Fri, Apr 15, 2011 at 11:14 AM, Alex Lydiate <[log in to unmask]> wrote:
>>> 
>>> I second Pat's suggestion to stick everything in Subversion and have done with it :)
>>> 
>>> And if we aren't going to do that, and stay on the Web and all, then lets do this:
>>> 
>>> Greg, you're speaking of versioning, great, if that's what you're after we can do that with OAI-ORE - it supports both the relation thisAggregation->IsAggregatedBy->thatAggregation.
>>> 
>>> If I were just talking about versioning, we could do everything in RCS, lol.
>>> 
>>> No, what I'm talking about is the entire Github experience.  The ability to easily find stuff that's interesting.  The ability to make a complete fork of a project.  The ability to contact the originator of the project and make a request to merge changes back into the original.  The ability to reliably track provenance in a bulletproof way.
>>> 
>>> Of course, the important difference between code and content is the relative value of forking.  In code, the expense of forking and maintaining a usefully evolving codebase separate from the originating project has been demonstrated conclusively to be very high, which is why Github is so valuable -- whereas in content, the expense of forking and maintenance is still indeterminate.  Is it better for everyone to maintain their own versions of OERs, or join them all together?  We don't know.  We're still guessing.  
>>> 
>>> --g
>> 
>> 
>> -- 
>> Alex Lydiate
>> Software & Systems Developer
>> LTEO - WH5.39
>> University of Bath
>> 01225 383576
>> 
>> !DSPAM:4da86a5d41081498514510!