On Mon, Jun 9, 2008 at 5:38 PM, Michael FIG <[EMAIL PROTECTED]> wrote: > "Krzysztof Kowalczyk" <[EMAIL PROTECTED]> writes: > >> On Mon, Jun 9, 2008 at 3:37 PM, Michael FIG <[EMAIL PROTECTED]> wrote: >>> once Ian figures out the best way to host user contributions): >> >> Move the repository to github.com? > > Does git actually clone the entire repository on checkout? If not, I > would be hesitant to put something like COLA into a proprietary web > application that may change its policies or availability without > notice. And have a 100MB limit.
It's a fair point about github.com being proprietary. As Steve said, every checkout has the full history of repo, since checkin 0, so there is no real lock-in as long as there is at lest one copy somewhere. There are also tools to mirror git repos between svn, both ways and you can trivially backup git repo by running "git pull" periodically via cron job. There are also free services like repo.or.cz and software that powers repo.or.cz is open-sourced so you can setup repo with the same web interface as repo.or.cz on your own server, just like you can setup svn server. Personally I trust github.com to survive longer than repo.or.cz, precisely because it charges for premium service, so they can subsidize large amount of freeloaders. I use github rather than repo.or.cz because I found repo.or.cz slow(er) and I have a paid account with github because I prefer to pay them few bucks a month that manage my own server and I like their web ui. As to size, the good think about git is that a repo containing full history of checkins is not much bigger that subversion checkout of just one version, thanks to more efficient storage method. Here are the sizes on my hard-drive of current idst checkout: Subversion, only current revision: kjkmacpro:src kkowalczyk$ du -sh fonc 79M fonc Git import via git-svn, full history, not optimized: kjkmacpro:src kkowalczyk$ du -sh fonc-git 117M fonc-git Git import via git-svn, full histor, optimized via git-gc: kjkmacpro:src kkowalczyk$ du -sh fonc-git 98M fonc-git Anyway, I mention github.com because it really solves the problem that I've encountered frequently with projects using centralized repository with untrusting and/or unresponsive maintainers (which is virtually all of them): making small contributions requires jumping through so many hoops that it's just not worth it to e.g. submit a msvc-compatibility patch (something I can usually do even without being expert on the software). And contributors of small things often turn into contributors of bigger things, so those projects loose not only small things but also bigger things. This is the problem you tried to solve by starting your own mercurial repo. I just prefer git because it has clearly won dvcs wars (and mercurial, bazaar, monotone, darcs lost) and since I already had to invest in learning git, I would prefer not to learn those other systems. I also like github.com because just using git (or mercurial or bazaar) is only part of the problem. You can use git as badly as svn. The other part is making forks trivial and forked branches visible to others. github lists forked repos in a nice timeline view which gives forks more equal footing and does all that without any additional burden on the maintainer of the orginal/official repo. -- kjk _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
