I watched Linus' video. I can honestly say I am less impressed with Git than I was when I started watching it.
If you listen carefully to his anecdotes, they pretty much contradict what he is trying to get across. He describes this utopian world where everyone has their own git repository of the linux kernel. People are all pulling changes from other people they trust and the Linux kernel gets better. In reality something else happens. There is one central repo anyone cares about, Linus'. The only person with commit access to that repo is Linus. People are basically submitting patches to his lieutenants and he is then pulling changes from them into his central repo when he is ready, or he would, except one of his lieutenants doesn't use Git. I actually found this whole thing disturbing. Now instead of there being a central repo which a number of trusted developers have equal commit access to, there is one person's repo which is more important than everyone else's. In order to get code into that repo, one has to get it into one of a number of other repos managed by other people. Then one starts dealing with merges. The only benefits I am seeing here (and I am not denying Git has those advantages) is that one can make multiple commits to one's local repo before posting patches to be imported into the main repo and that working on a branch is slightly easier in that it doesn't need to touch the main repo. If you look at the way the parallel OpenMP branch of MPIR has been worked on, however, it isn't that much different. Mark Glisse and I have been posting our code online (as we'd have to do with Git) and "pulling" each others changes and trying them out. We have been working in incompatible changes, in the sense that merging doesn't make sense (yet). And neither of us is happy enough with our code to commit to the central repo, so the code has actually stayed out of there. One thing Git would have done for us is when Marc's machine in France went down, I wouldn't have had to wait for him to email me his code again, because I would have it somewhere in my Git repo. Of course this was just an oversight on my part. I accidentally overwrote the file Marc sent me. Though I am not denying Git would have helped with that. Anyhow, I still feel Git is the best solution out there. There are now 32 and 64 bit TortoiseGit clients for Windows. Git is written in C, which is a language I understand, and it was written with performance in mind. It is supposedly an order of magnitude faster than alternatives, and it the power to do exceedingly complicated things, such as keep track of functions moving between files. For my money, it is the only way to go. Having said that, I am sceptical it is going to make much of a difference for us until we grow as a project beyond about 10 regular contributors. Bill. 2009/7/8 Bill Hart <[email protected]>: > 2009/7/8 William Stein <[email protected]>: >> >> On Mon, Jul 6, 2009 at 8:42 PM, Bill Hart<[email protected]> wrote: >>> >>> I've started writing some development documentation, which will take >>> quite some time to complete. Here is what I have so far: >>> >>> http://sage.math.washington.edu/home/wbhart/mpir-development.pdf >> >> * p-adic --> $p$-adic >> >> * is not on software end users --> is not on software for end users >> >> * " but on the needs of developers as users." -- what does that mean? >> >> * "Finally, development of MPIR is focused largely on extreme performance. >> This >> is of course the most fun component of working on MPIR, as other developers >> ..." >> >> I think it would be pretty cool to include a plot of the mpirbench >> score over the last few years on some architecture here. You could >> emphasize that while clock speeds have stood essentially still during >> the last 5 years, MPIR/GMP's speed has more than doubled. >> >> * "Most extensive high level libraries which use MPIR routines >> actually use the mpn layer," -- what does that mean? Is Sage or NTL >> a "high level library"? It doesn't use mpn... > > Sorry, but NTL does use mpn's, extensively. And of course Sage does, > via Pari, FLINT, zn_poly, NTL and in many other places. I think roed > even uses them directly for some things (I'm not 100% sure I think I > just remember seeing that). > >> >> * "Windows and linux differ" -- capitalize Linux. (this problem is >> all over in the doc) >> >> * " 32 bit OSX" --> "32-bit OS X". In general, replace "OSX" >> everywhere by "OS X". >> >> * "than on linux, however a longstanding deficiency of MPIR" -- I >> think it should be "linux; however,". >> >> * "Arm" --> "ARM" >> >> * "The mpz, mpq anf mpf layers" --> "The mpz, mpq and mpf layers" >> >> * Your asterisked lists would look a lot better (I think) if you used >> >> \begin{itemize} >> \item the entry >> ... >> \end{itemize} >> >> * "type make check to run all these tests." --> "type {\tt make check} >> to run all these tests."; same for "make tune" later, etc. >> >> * "/doc/devel contains" --> "doc/devel contains" >> >> * " on 32 bit X86 code " --> " on 32-bit x86 code " >> >> * "build.vc9 - visual solutions files for MSVC " --> "build.vc9 - >> Visual Studio solutions files for MSVC " >> >> * "svn co http://modular.math.jmu.edu/svn/mpir/mpir/trunk mpir-trunk " >> I own "mpir.org", so I could probably use proxying to make it so >> "svn co http://svn.mpir.org/mpir/trunk mpir-trunk" >> would work. Thoughts? > > I think Jason Martin doesn't want to keep hosting the repo. So not > much point until someone else volunteers. > >> >> * I tried the above command and got the following: >> "Last login: Tue Jul 7 16:31:04 on ttys004 >> You have new mail. >> teragon:~ wstein$ cd tmp/ >> teragon:tmp wstein$ wget svn co >> http://modular.math.jmu.edu/svn/mpir/mpir/trunk mpir-trunk >> --17:04:21-- http://svn/ >> => `index.html' >> Resolving svn... 72.13.86.194 >> Connecting to svn|72.13.86.194|:80... >> >> [hang for 10 minutes and I give up!!!!!]" >> > > why did you put wget? > > Without wget it takes 30 seconds to check out the entire flint repo, > including every past released version of FLINT and trunk. > >> * <rant> >> >> SVN sucks. It's the dark ages. It's sad on page 8 that you can't >> just tell the developer -- >> (1) change files, > > svn lets you do that.... > >> (2) check into to your local repo > > no need, any changes made are automatically in your local working > copy, unless you are adding new files, in which case you do > > svn add filename > > to put them under revision control > >> (3) change more files, check in more changes > > nothing new here, same as above, no need to "check in", just change the files > >> (4) When you're ready, post patches that any other developer can >> just try out in their local repo. > > svn diff > file.patch > > post to wherever or whomever you like. > > As far as the operations go that you have just listed, it is actually > easier to do them in svn than in HG. > > One advantage of HG over SVN is that you can make lots of local > commits before a global commit. The main advantage of that is the > possibility of a more atomic commit log. The GMP project certainly has > that. > > As far as work flow goes however, HG is irrelevant for my purposes. My > editor has all the features for keeping track of and reverting local > changes, that I need. I don't need my revision control software to do > that. > > As for sharing my work as I go with others, and collaborating, svn > forces a different work flow for that. I cannot send someone some > patches that represent a half done job, get them to work on part of it > while I work on another part and keep the whole thing out of the > central repo so it doesn't bother other developers, then have both of > us commit our respective patches to the central repo when done. > > The standard way of doing this with svn is to make a branch in the > central repo and give the community of people who want to collaborate > on that branch write access to the repo. Then it is exactly the same > as sending patches to one another. You just do it via the repo. For > large projects with multiple branches, it eventually becomes > prohibitive. With three developers, or even 10 it works just fine. > > SVN does force a slightly different workflow, and in terms of internet > bandwidth, it is more expensive as Brian found out. But it still > works, just fine. > > (Brian's issue can easily be resolved by him making a copy locally on > his hard drive then using the svn switch command. Then he could > download multiple branches without checking the entire branch out > every time - only the changes from from the point it was branched, are > sent.) > >> >> You promised me you would watch Linus's talk here: >> http://www.youtube.com/watch?v=4XpnKHJAok8 >> Please keep in mind that Linus is arguably the most successful person >> ever at organizing and growing a large open source project. >> >> </rant> > > I gave up on this issue again. The one person who is supposedly > maintaining the git repo has no time to keep doing so. I can't even > get him to rebase it. No one cares about this issue. Or everybody > cares, but no one who has any intention of setting up a repo or > maintaining it or actually contributing to MPIR, cares. > > It annoys me that I read a document about what makes an open source > project successful. It is written by one of the authors of svn. I'm > told to watch a video by Linus, who wrote Git. Brian wants to use Hg > because he thinks Git users have freetard tendencies. Gonzalo assures > me Darcs is far superior technologically to Hg or Git. > > This issue just frustrates the hell out of me. It's like arguing > politics or religion. > > The fact of the matter is the most popular revision control software > for Windows users writing C code is svn. In fact the most popular > revision control software fullstop is svn. > >> >> * "ammend" --> "amend" >> >> Awesome! Please let me know when you post a new version with all the >> new typos fixed. >> > > Thanks for all the corrections. By the way, despite it saying that it > is, this document is not actually in the repo yet. No reason. I just > didn't bother putting it there yet. > > Bill. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
