[MEI-L] Google Code deprecating downloads

Andrew Hankinson andrew.hankinson at mail.mcgill.ca
Wed Nov 20 02:30:46 CET 2013


Perry, I hear you about GitHub and non-developer types. There’s a quite a bit of “lingo” associated with git & GitHub. If we do switch platforms, we must ensure everyone is comfortable with the switch and the changes in lingo.

I would voice some opposition to placing the .zip files in the Subversion repository. Since ZIP files are binary files, version control systems (including Git) don’t deal with them very well. They can’t track the changes in these files, so every change to a binary file means that an entirely new copy of the file is tracked by the subversion system.

Since the release file is already ~9MB, multiple copies of this file, along with the code, will make the Subversion repository grow pretty quickly. As the repository grows, this will slow down both checking out and committing.

I also don’t think this has any inherent advantages. If we want to provide a way to access the releases of MEI without asking people to understand the lingo of any repository platform, there could be nothing clearer than a big “Download” button on the front page of music-encoding.org, with the files hosted on the project’s web server, rather than in the Google Code repository.




On Nov 19, 2013, at 6:07 PM, Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu> wrote:

> We're already providing downloads from music-encoding.org.
> 
> For individual files, links point a location inside a tag, e.g., http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-CMN.rng, but for a "package" of files, links point to files in the download area, e.g., http://music-encoding.googlecode.com/files/MEI2013_v2.1.0.zip.
> 
> It's the last kind that's going to become problematic.  Putting the ZIP file inside the repo and then making it part of a tag makes it accessible.  Maintaining the links at music-encoding should be manage-able.
> 
> --
> p.
> 
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> ________________________________________
> From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Peter Stadler [stadler at edirom.de]
> Sent: Tuesday, November 19, 2013 11:38 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Google Code deprecating downloads
> 
> Am 19.11.2013 um 16:22 schrieb Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> 
>> What Andrew said. Also, using GitHub "releases" could give us a consistent way of tracking and distributing MEI releases. Were GitHub to disappear, their releases are nothing more than Git tags, so they could be migrated without too much hassle.
> Yes and no. When creating a git tag (and pushing it to GitHub) it shows up as a GitHub release. But, you can add additional binaries and a change log that goes „beyond Git artifacts“ [1]. Just wanted to mention though I still prefer that option …
> 
> This GoogleCodeWiki hack seems a little bit too hacky to me but we could simply provide downloads directly from music-encoding.org as well. There are currently four files in the downloads section from GoogleCode — that should be manageable?! As I understand the "Change to Google Code Download Service“ it only affects this downloads section, not the repository.
> 
> Best
> Peter
> 
> 
> [1] https://github.com/blog/1547-release-your-software
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l




More information about the mei-l mailing list