[sakai-core-team] Work on migrating to github

[Hedrick Charles]

When I can find someone to test it, I’m going to look at osp and metaobj.

> On Dec 22, 2014, at 7:34:25 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> 
> So maybe not include the docs in the migration. We were going to get clever(er) with the docs weren't we? I think a cleanup before the migration would be a fine idea, and much better than splitting it between SVN and Git. I never liked the docs in the source code TBH.
> 
> On Tue, Dec 23, 2014 at 9:18 AM, Matthew Jones <matthew at longsight.com <mailto:matthew at longsight.com>> wrote:
> But in git, you can specify a depth level right? Then you won't get a full local history, and also won't get any of those other files either. I'm not super concerned about the full history or how much is stored on github. (They give you 1GB per repo which we are unlikely to hit)
> 
> Though it is probably nicer/easier to clean this up and filter this from the history before the load than after, it looks like we could do it sometime in the future too (https://rtyley.github.io/bfg-repo-cleaner/ <https://rtyley.github.io/bfg-repo-cleaner/>), like maybe let next 2016's Earle worry about it. ;)
> 
> 
> On Mon, Dec 22, 2014 at 5:08 PM, Earle Nietzel <enietzel at anisakai.com <mailto:enietzel at anisakai.com>> wrote:
> Even if you clean it up its still going to be in the history!!!
> 
> On Mon, Dec 22, 2014 at 5:05 PM, Matthew Jones <matthew at longsight.com <mailto:matthew at longsight.com>> wrote:
> Yeah, we can adjust this so only osp and metaobj have the same permissions as they do presently. In-case anyone still has to commit to there. Probably easier than moving it somewhere else. Just exclude them from the github commit.
> 
> Ideally we'd have a reference cleanup or split out the non-production stuff, as more than half of it (30-40MB) either is out of date or only reference material. Basically the docs directory, all of the old editors and other javascript no longer used in the webapp and all of the sample skins, which by 11 won't really be useful. There's a lot of stuff that can really add up to the initial checkout size and space on disk. For some people it doesn't matter but we have some schools in low bandwidth countries were 100MB can take awhile to checkout.
> 
> I guess it's not a blocker for github but for sure would be nice to focus on cleaning up as it would have a big overall impact, as much as code cleanup has on maintainability.
> 
> Thanks!
> 
> 
> On Mon, Dec 22, 2014 at 4:35 PM, Charles Severance <csev at umich.edu <mailto:csev at umich.edu>> wrote:
> 
> On Dec 20, 2014, at 11:48 AM, Matthew Jones <matthew at longsight.com <mailto:matthew at longsight.com>> wrote:
> 
>> - OSP 
>> 
>>   I think we should just either leave this in SVN, possibly just migrate to contrib or create a separate git repository. This is no longer included by default in 11 and it's one of the biggest pieces of code in Sakai (13MB in the git repository). Also excluding metaobj and warehouse would save 20 MB. I believe that all 3 of these projects should either be in svn contrib or in a completely separate github repository from the start.
> 
> I think this is a fine idea as long as we can enable commits to continue within OSP trunk without opening up the rest of trunk. 
> 
>> - Reference
>>   By far the largest chunk of space in a checkout is the reference folder, occupying over 100MB alone on disk. Large portions of this are documentation, optional tools and optional skins not required to actually get Sakai to function. At Longsight, we keep reference in a separate repository (in github) and I believe it would be a good idea to also keep reference separate. I don't love the idea of submodules but I think it does make sense for reference since it would save a lot of time and space in a typical checkout.  Additionally help may also be useful to have a a submodule along with so it's easier to update and it seems like help is tied into the reference documentation. I could go either way with help.
> 
> Splitting this out just because it is big seems not all that necessary.  It is too bad we don't have time to remove the non-production bits and have them be elsewhere - but unless we can cleverly break this up I say just leave it in place.
> 
> /Chuck
> 
> 
> 
> _______________________________________________
> sakai-core-team mailing list
> sakai-core-team at collab.sakaiproject.org <mailto:sakai-core-team at collab.sakaiproject.org>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team <http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team>
> 
> 
> 
> -- 
> earle,
> asahi net int.
> 
> 
> _______________________________________________
> sakai-core-team mailing list
> sakai-core-team at collab.sakaiproject.org <mailto:sakai-core-team at collab.sakaiproject.org>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team <http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team>
> 
> 
> _______________________________________________
> sakai-core-team mailing list
> sakai-core-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20141222/6468edc8/attachment-0001.html