On Feb 7, 2011, at 11:16 AM, Max Horn wrote: > Hi there, > > I would like to emphasize something which Charles Lepple already hinted at: > > Why not use git (hosted at github.com, ideally) for devs, and subversion for > end users? > > Let me explain where I see the advantage: > > Git is more modern and advanced than Subversion, and has features that I > personally consider very helpful for developers, based on experience. Yet I > also see good reasons for using Subversion, at least for end users. The main > point being that binaries for svn ship with Mac OS X, meaning "fink > selfupdate-svn" would work immediately after a boostrap.
I like it. That could work well too. I'd prefer to use git myself. :) > But by using git + github.com, we could combine the advantages of both > Subversion and git: > > * github.com offers a free Subversion <-> git bridge, even including > (necessarily limited) write support. And yes, over http! See here: > <https://github.com/blog/626-announcing-svn-support> > <https://github.com/blog/626-announcing-svn-support> That's very cool. > * If some of you prefer Mercurial: No problem, you can use hggit to access a > git repository via the mercurial userland. I tested this successfully in the > past. > <http://hg-git.github.com/> Which we have in fink. :) Also, whenever cvs comes back, I've got an update to the newest git that slashes its list of dependencies. Turns out that most of the perlmod dependencies were only needed by git-send-mail so I spun it off into its own package. Debian does the same thing. > * git *can* be accessed through http for both reading and writing, i.e. also > through a proxy. Again, I have used this successfully in the past. On > github.com, this is always possibe. > > * with github.com, we get various nice bonus features, like the ability to do > code reviews, and to use many custom service hooks, much more than what > SF.net offesr. > > * since git is a DVCS, it's quite easy to switch to a different "master > repository". Meaning: If we need to move it to a new location (say away from > github or sf.net to a server of our own), this is a one-line command which > takes virtually no time to execute. I.e. we are not as trapped as we are with > the SF.net CVS offering > (granted, SVN also helps this with "svn switch") > > * git (like mercurial) has many advanced features over Subversion. Some tools > that really saved me a lot of time in the past include "git grep" (greps the > whole repository; some orders of magnitude faster on my system than grepping > through a CVS/SVN checkout); "git bisect" (which helps track down > regressions; not so useful for the distro tree, I guess); great branching > support (e.g. I imagine that 10.4/stable, 10.5/unstable, etc. could be a > separate branch each, and we'd have multiple "checkouts" for each inside > /sw/fink/dists); great merging support; and many other things. > > * the "experimental" tree could completely go. Instead, each dev could simply > have a personal "fork" of the main Fink repository, in which modified > packages go. Once a package is ready for the regular repository, it can be > merged into that, leaving the version history intact > > * Even better, non-devs can also make forks, but instead of directly merging > their changes, they can file a "pull request", i.e. they can ask the Fink > team to integrate their new package or package updates. Consider this as an > advanced alternative to the Package submission tracker. Only that it is > possible to accept new packages/fixes with a single button click from inside > the browser. And if the submission is lacking, you can provide feedback and > request changes, and even comment on the submitted code -- even making line > annotations. This really simplifies patch submissions for everybody involved > (once you learned the minimal git you need to submit stuff this way, at > least). > > * People asked for by-file access control. Yes, this is possible with git. > See here > <http://progit.org/book/ch4-8.html> > However, I am not sure (or rather, am doubtful) whether github supports this > (it would be easy enough to ask them whether they support by-file access > control). If we were to setup our own server, though, this is the way to go. This all sounds good and I'm not opposed to it. I suggested switching to svn as the path of least resistance. It would require the least work and be the least disruptive change, I believe. I was a little nervous about changing VCS and host at the same time, especially since we'd need to continue using sf.net for a while anyway to get users updated to whatever we change to otherwise people using cvs would get stuck. BTW, here's the patch I used to implement selfupdate-svn: http://homepage.mac.com/danielj7/selfupdate-svn.patch It's based on selfupdate-cvs but is much simpler since there's no need to login first and no difference between anonymous and developer access. Note that it's currently hardcoded to use my local svn repository. You'd have to change the $svnrepository value if you want to experiment. Daniel ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
