On Tue, May 4, 2010 at 4:03 PM, Allison Randal <[email protected]> wrote: > So far, the compelling reason I've been given for why we should move to git > is branch merging. But, it's been demonstrated quite effectively that the > git merging tools work on an svn data-store.
A more compelling reason from my perspective is that the entire repository, including it's complete history, is mirrored more rigorously. If the server goes down now, people have their checkouts but very few people have the full history of the repo. With git, every user would have the complete history, and disasters would be mostly avoided. > The funny thing is, AFAIK no one whats to switch to distributed development > patterns. The git advocates want to use git as a centralized repository. If > we were planning to move to a more distributed development pattern, I would > consider git a greater advantage. To play devil's advocate here, what if we did? Every month, the release manager "owns" the master branch, and only cherry-picks in the commits that he wants to see in the release, then releases it. This kind of system would put a little bit more responsibility on the shoulders of the release manager, but it could have several other benefits. The "release master" branch could be kept clean and pristine all month by only cherry-picking stable commits from all the "dirty" development branches around. Or, we could have a tiered system: A central "integration" repository, where people would dump dirty changes, and then a "release master" repository that was cleaner and used by the release manager to make releases. If our development paradigm changed, we would need to find better tools to support it. >> (ii) There are at least three distributed VCSes that, on the basis of >> their adoption by other large, open-source projects, deserve our >> attention: git, mercurial and bazaar. What are the strengths and >> weaknesses of each? Are there people we can speak with who have >> extensive experience with two or more of these? > > I consider all three equally good. Well, of the three I actually have a > personal preference for bazaar, but they are technically equivalent. > >> (iii) If we do decide to move to a distributed VCS and settle on a >> particular VCS, what shall our migration plan be? (Note: On the basis of >> my past and current experiences, this is the issue that needs the most >> discussion but will likely get the least.) > > This I would like to see a great deal more on. About the only way I'm likely > to be comfortable with a move to git is if we do an entire mock run on the > migration to a test server, including the svn-dump-and-git-import, the > integration with Trac, email notifications, and our tools for access control > management. We need to figure out hosting, if our current hosting can > support git, if we'd use a service like githib. We need to figure out if > Trac integration will work if git is hosted on a different box (svn and Trac > have to be hosted on the same server for the integration to work). I want to > know if we can do bzr and svn mirrors from git. > > I also want to see the equivalent of our docs/project/committer_guide.pod > written for git. I want to see agreement among the git users on a project > standard for how we setup our local repos, how we do checkouts, commits, > branches, merges, where we publish our private branches, etc. I know git > allows for dozens of different styles of development, but it makes it > enormously difficult to collaborate with other developers when you have to > work around a dozen different ways of doing things (I've already been bitten > by it, and we're not even using git all that heavily at the moment.) I want > a plan for how we'll refer to revisions, and if there is a good way to save > existing references to our 46286 (and counting) revisions, a policy on how > we'll tag releases, and details on how we'll restrict our git hosting to > prevent the more destructive repository-changing commits that git allows. > > Ideally, I'd like to spend some time talking to a sysadmin who has done svn > migrations and maintains git repos. Specifically, one who is willing and > open to talk about the disadvantages of git as well as advantages. (All > software has disadvantages. I worked as a sysadmin for years, and I don't > believe anyone who tells me a particular package has none.) These kind of > infrastructure decisions are trade-offs, working out if the mix of > advantages/disadvantages of one system are a better fit for the particular > project's needs than the advantages/disadvantages of another system. > >> (b) Venues for discussion: >> >> (i) As suggested above, I don't think IRC is a satisfactory venue for >> this discussion. In fact, I'm going to state right now that between now >> and YAPC I'm not going to pay attention to anything whatsoever said on >> #parrot concerning Parrot's VCS choices. > > Unfortunately, I won't be at YAPC::NA. Whatever parrot devs are there can > certainly get together, but it wouldn't be effective at resolving this > conversation. > > I also get the impression that the git advocates would like an answer soon, > so the end of June may be too long anyway. > > Allison > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
