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

[Steve Swinsburg]

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>
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/),
> 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>
> 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>
>> 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>
>>> wrote:
>>>
>>>>
>>>> On Dec 20, 2014, at 11:48 AM, Matthew Jones <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
>>> 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
> 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/20141223/31bde760/attachment.html