On Wednesday 15 February 2012 18:04:51 Eric S. Raymond wrote: > Mark de Wever <[email protected]>: > > Personally I see not too much advantage by Git, git-svn works good > > enough for me. However IMO the uptime of GNA is getting lower over the > > years (it might be selective memory as well). > > It probably isn't. I've noticed it as well.
I haven't really had any persistent problems with gna.org's service for a long while myself, other than the recent, prolonged downtime we all know of, and that can be mostly attributed to poor planning. Better staffed services with fresh codebases occasionally have to deal with things like distributed denial of service attacks or security breaches, so I'm not sure there's a real difference for a project like Wesnoth where there isn't constant 24/7 activity. That isn't to say there isn't a _problem_. I just think there's too much emphasis on a rather insubstantial benefit along that line. I have repeatedly expressed concerns for moving to Git on IRC, so I'll try to summarize them here for those who have not (been able) paying attention: 1) With SVN, the bulk of the initial download on 'svn checkout' appears to be the snapshot of HEAD that serves as the client's reference to resolve differences against the BASE revision. The size of the uncompressed source distribution tarball we offer through SF.net should be a good reference for this size. (I'm deliberately ignoring metadata and the visible file duplicates in the checkout tree.) Using Git, users (i.e. developers, prospective contributors, early adopters and players taking advantage of tags) will have to download the entire history the first time in one go (git clone doesn't currently have a mechanism to resume interrupted operations). Taking my git-svn tree as a reference, that would be something around 1.7 GiB. I wouldn't have been able to download this much when I first joined, and I'm not able to at the moment (nor for the foreseeable future) either. This means that, assuming the service we choose doesn't offer something like that, we'd need to host periodically-updated (possibly monthly) repository clones that could be downloaded in a more convenient fashion using a tool like wget. 2) The hosting service must either allow us to install our own hooks on the upstream repository, or provide a set of usable hooks including the CIA.vc notifications system and a commits mailer. I know from experience Gitorious doesn't offer either option. Github has a vast set of hooks (including CIA.vc) and they seem to be open to adding new ones according to the needs of their users. SF.net appears to use the second approach. In the matter of CIA.vc hooks for Git, all those I have seen so far have annoying limitations such as the inability to present real merges in a useful fashion, commits being reported out of order, or no tag object reports. I believe I have seen CIA reporting commits to hosted KDE projects addressing some of these points, but I haven't found the hook's source yet. 3) The learning curve and organization. At the beginning (and even afterwards, as new people join the project) it will be very chaotic unless someone steps forward and provides users with links to documentation (since IME even code developers fail to RTFM at times), and most importantly, style guidelines covering commit style/format, usage of branches, real merges vs. rebasing, and so on. -- Regards Ignacio Riquelme Morelle <shadowmaster>
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
