On 5 Dec 2007, at 21:52, Dan Stowell wrote:
I don't really see why svn is overkill. The one humungous advantage it has is that when a quark developer checks in an updated version of a quark, users are able to update - they don't have to wait for the dev to get round to exporting a clean bundle for them etc etc.
Well just overkill in the sense that it provides a whole lot of functionality that isn't particularly needed in a package manager. It wasn't designed for that after all. That's not to say it's not working.
Exporting is trivial IMO, but a bigger issue is that the quarks repository is not usable for in progress development or making material available for wider testing, since it's being used for live distribution of 'stable' versions as well.
Is the main motivation that curl comes as default with OSX? Are there other motivations? (The starter for all this discussion was plugin binaries, but whether or not to use svn as the sync tool is tangential to that.)
Well, IIUC we can't use svn for distributing binaries on SF as they don't want their svn repositories used for that purpose, so we'd have to use something else at least for UGens. curl was mentioned I believe in the context of discussing that. Inclusion in the OS is desirable of course (although I don't know if it comes with Windows), but another solution would be to include binaries of svn / curl / whatever with SC binaries, as I've suggested in the past. It's definitely a problem for casual users to have to deal with installing and configuring svn to use quarks, which sort of goes against the convenience idea...
curl would make a sort of sense, as that's basically what it's for (grab stuff from URLs), but it certainly could be something else. svn only talks to svn repositories however, so it can't be used with anything else or for generic downloading. So either you need to use svn + 'yet to be determined substitute' for UGen quarks, in which case I think it makes sense to just use 'substitute', or you have to move from SF.
I'd be happy to host a repository with binaries galore on our server (we already have a couple of repositories working), but I imagine that the objection will be the same as when I offered to host the lists: Institutional affiliations can change (as true for anyone else as me, fair enough), which may leave things orphaned or needing to be moved. SF will presumably have longevity, but won't let you host binaries.
So... suggestions? S.