Long-time Parrot contributor kid51 posted a nice comment on my previous post about Git and SVN. He had some issues with the proposed distributed workflow I suggested. As my reply started to grow far too long for the stupid little blogger comment edit box, I realized I should turn it into a full blog post.
I've been pretty conflicted myself over the idea of a release manager. On one hand releases are boring which means anybody can do them and they don't require a huge time commitment. On the other hand, there is hardly a lot of "management" that goes on in a release: The release manager has some authority to declare a feature freeze and has some ability to select which revision becomes the final release; but that's it. Sure release managers also try to motivate people to perform the regular tasks like updating the NEWS and PLATFORM files, but my experience is that the release manager ends up doing the majority of those tasks herself. I really feel like we need more direction and vision than this most months, and the release manager is a good person (though not the only possible person) to do it.
Our releases, especially supported releases, have had certain taglines stemming back to PDS in 2008. The 1.0 release was famously labeled "Stable API for developers" and the 2.0 release was labeled "ready for production use", when even a cursory review shows that these two releases hardly met their respective goals. A release manager with more authority to shape that release, and more authority to shape previous releases as well might have done more to change that. A development focus, be it for weekly development between #ps meetings or for a monthly release, only matters if somebody is focusing on it and motivating the rest of the community to focus as well. That person either needs to be the architect or some other single authority (though playing cheerleader and chief motivator constantly would be quite a drain on that person) or the release manager. The benefit to using the release manager to motivate the team and shape the release is--even though it's more of a time commitment for the release manager--that we share the burden and no one person gets burnt out month after month.
A tiered development system has a number of benefits. Bleeding edge development can occur unfettered (as it happens now in branches). From there we can pull features into integration branches where we assure all the assorted changes and new additions work well together. Development releases can be cherry-picked to represent the stable baseline features that we want people to play with and rely on, and long-term supported releases would represent only those features which are tested, documented, and worthy of being included under our deprecation policy. I don't think end-users of our supported releases should ever be exposed to features marked "experimental", for instance, or any feature at all that we don't want covered by our long-term deprecation policy. If any feature included in a supported release must be deprecated and cannot be removed or fundamentally altered for at least three more months, we should be particularly careful about including new things in a supported release, and there should be some level of gatekeeper who is able to say "this thing isn't ready for prime time yet". That person, I think, should be the release manager.
Compare our system for dealing with new experimental features (Goes into trunk, maybe with mention in #ps but with very little fanfare, and is then automatically included in the next release unless somebody removes it), to a system where features are added to a development branch, vetted, tested, documented, and then pulled into a release candidate branch only when it's known by the community to pass muster. I think that's a much better system and would lead us to releases with higher overall quality and stability.
All this sort of ignores your point, which is an extremely valid one, that switching to Git represents more than just a small change in the commands that a developer types in to the console. Yes, it's a small difference to say "git commit -a" instead of saying "svn commit". Yes, it's a small personal change for me to commit locally and then push. The far bigger issues are the community workflow and even the communtity culture changes that will occur because of Git. These things don't need to change, we could lock Git down and use it exactly the way we use SVN now, but I don't think any of the Git proponents in the debate want it that way.
I would much rather plan for the changes in work flow and even build enthusiasm for them primarily than sell the small changes in tooling and then be swept up in larger culture changes that nobody is prepared for. I think we should want these changes and embrace them, in which case Git is just the necessary vehicle, and not he end in itself.
Showing posts with label Git. Show all posts
Showing posts with label Git. Show all posts
Thursday, May 6, 2010
Wednesday, May 5, 2010
SVN or Git
As I mentioned in my last post, the discussion about whether we move to Git from SVN has been raging pretty hard in the past few days, and while the general opinion seems to be one in favor of a move, there certainly isn't concensus on the point just yet.
I'm in favor of Git, although I certainly wouldn't list my bent as a "passion" as some opinions in the community have been described. In Parrot world I use SVN exclusively. I could use git-svn, or I could try to use dukeleto's Git mirror on Github, but I don't. As far as I am concerned those add an additional layer of complexity, an additional abstraction that layer that I can ignore most of the time until something goes wrong. It simply isn't worth it to me to try and force a Git interface onto Parrot's SVN repository.
Let me tell a short story.
When I was a graduate student I was given a "computer" for my "desk" in my "office" that I could use to do my normal school work and also to develop my thesis. This computer was a complete beast of a performance machine. At least, it had been several years earlier when it was first purchased. By the time I got it, circa 2006, it's 12Gb hard drive and screaming 128Mb RAM weren't quite as impressive comparatively.
I was paranoid about data integrity, considering I was working on the most important academic project of my whole life on the least qualified machine on campus. So, I took some steps to help shore up my defenses. First thing, I scrounged together several other small harddrives from other dusty computer carcasses. I removed the CDROM drive and jammed four HDDs into my case. Two of them were just hanging inside because there wasn't enough space to physically mount them all. I also had a shared network drive supplied by the university, a flash drive, and a personal laptop.
I set up SVN on the computer, and backed up my work as follows: On the second drive was where my work was (the first drive was barely large enough to hold Windows XP and the other software I needed). I had a script that I used to simultaneously svn co my work to the third drive and xcopy my working directory to the fourth. I had an hourly task that would then backup my svn repo from the third drive and an xcopy of the directory on the fourth drive to the network shared drive. At the end of each day, I would xcopy my working directory to my flash drive, go home, and store a copy on my personal laptop. About once a week I would email myself a copy of my thesis paper, in hopes that if all else failed, at least Google could safeguard the all-important final deliverable.
This may all sound excessive, but by the end of the year I had lost two hard drives (one of which actually caught on fire), my flash drive got crushed, and the network drive has experienced several outages.
Story aside, the idea that there is only one copy of the entire history of the Parrot repository (or even two copies, assuming the server has a tape backup plan) is hardly reassuring to me. This is why I really like the Git idea that everybody has a complete copy of the entire history of the repository.
Let's look at things from a different angle: Git is a distributed version control system. While it certainly supports it, there is no true need for a single, central, "master" repository to work from. We could, as a community, radically change our workflow if we had Git. If we were going to use it exactly the same way as we currently use SVN, there really isn't enough of a reason to switch.
What we have now is a single master trunk, which is where most of the action takes place. People make branches, do work, merge them to trunk. Then, on the second Tuesday of every month, somebody copies trunk to a tag, calls it a release, and we continue on with our normal development.
So let's imagine a different workflow. I'll posit one example, but this certainly isn't the only choice. With Git, everybody has their own local branch where they do work and make commits. Hell, "everybody" here can be a much larger group than the committers we have now: Anybody can make a fork and do work on their own local branches. We could have something like a master integration branch where trusted committers could pull changes from the entire ecosystem. The integration branch would be more like a testbed and less like a master reference copy.
From the integration branch, a monthly release manager would cherry pick the good stable features of the integration branch into a release master branch. At the end of the cycle, the release manager's master branch would get tagged as a release, and would become the new baseline integration branch. Remaining changes from the previous integration branch could be pulled in if they were worthy or if they gained more maturity. At that point, the old integration branch could disappear, and the cycle starts again.
This idea is more complex than our current system, but it does have a few nice features. First, we can strive for higher-quality releases by keeping closer track of what ends up in the release branch. Second, we can try to get more people involved by allowing everybody to create a development branch to do "real" work, not just our designated committers. Third, the release manager has more control over releases, including being able to shift the focus on the release and be able to drive it in a way that is not possible now.
I like Git, I like the idea of it and I like the things that it makes possible. I don't dislike SVN, but it doesn't have any compelling features that make me want to stay with it. SVN is good but not great, and there's one usage pattern for SVN that works but is limiting. SVN isn't hurting Parrot, but it's not lifting us up to the next level either.
I'm in favor of Git, although I certainly wouldn't list my bent as a "passion" as some opinions in the community have been described. In Parrot world I use SVN exclusively. I could use git-svn, or I could try to use dukeleto's Git mirror on Github, but I don't. As far as I am concerned those add an additional layer of complexity, an additional abstraction that layer that I can ignore most of the time until something goes wrong. It simply isn't worth it to me to try and force a Git interface onto Parrot's SVN repository.
Let me tell a short story.
When I was a graduate student I was given a "computer" for my "desk" in my "office" that I could use to do my normal school work and also to develop my thesis. This computer was a complete beast of a performance machine. At least, it had been several years earlier when it was first purchased. By the time I got it, circa 2006, it's 12Gb hard drive and screaming 128Mb RAM weren't quite as impressive comparatively.
I was paranoid about data integrity, considering I was working on the most important academic project of my whole life on the least qualified machine on campus. So, I took some steps to help shore up my defenses. First thing, I scrounged together several other small harddrives from other dusty computer carcasses. I removed the CDROM drive and jammed four HDDs into my case. Two of them were just hanging inside because there wasn't enough space to physically mount them all. I also had a shared network drive supplied by the university, a flash drive, and a personal laptop.
I set up SVN on the computer, and backed up my work as follows: On the second drive was where my work was (the first drive was barely large enough to hold Windows XP and the other software I needed). I had a script that I used to simultaneously svn co my work to the third drive and xcopy my working directory to the fourth. I had an hourly task that would then backup my svn repo from the third drive and an xcopy of the directory on the fourth drive to the network shared drive. At the end of each day, I would xcopy my working directory to my flash drive, go home, and store a copy on my personal laptop. About once a week I would email myself a copy of my thesis paper, in hopes that if all else failed, at least Google could safeguard the all-important final deliverable.
This may all sound excessive, but by the end of the year I had lost two hard drives (one of which actually caught on fire), my flash drive got crushed, and the network drive has experienced several outages.
Story aside, the idea that there is only one copy of the entire history of the Parrot repository (or even two copies, assuming the server has a tape backup plan) is hardly reassuring to me. This is why I really like the Git idea that everybody has a complete copy of the entire history of the repository.
Let's look at things from a different angle: Git is a distributed version control system. While it certainly supports it, there is no true need for a single, central, "master" repository to work from. We could, as a community, radically change our workflow if we had Git. If we were going to use it exactly the same way as we currently use SVN, there really isn't enough of a reason to switch.
What we have now is a single master trunk, which is where most of the action takes place. People make branches, do work, merge them to trunk. Then, on the second Tuesday of every month, somebody copies trunk to a tag, calls it a release, and we continue on with our normal development.
So let's imagine a different workflow. I'll posit one example, but this certainly isn't the only choice. With Git, everybody has their own local branch where they do work and make commits. Hell, "everybody" here can be a much larger group than the committers we have now: Anybody can make a fork and do work on their own local branches. We could have something like a master integration branch where trusted committers could pull changes from the entire ecosystem. The integration branch would be more like a testbed and less like a master reference copy.
From the integration branch, a monthly release manager would cherry pick the good stable features of the integration branch into a release master branch. At the end of the cycle, the release manager's master branch would get tagged as a release, and would become the new baseline integration branch. Remaining changes from the previous integration branch could be pulled in if they were worthy or if they gained more maturity. At that point, the old integration branch could disappear, and the cycle starts again.
This idea is more complex than our current system, but it does have a few nice features. First, we can strive for higher-quality releases by keeping closer track of what ends up in the release branch. Second, we can try to get more people involved by allowing everybody to create a development branch to do "real" work, not just our designated committers. Third, the release manager has more control over releases, including being able to shift the focus on the release and be able to drive it in a way that is not possible now.
I like Git, I like the idea of it and I like the things that it makes possible. I don't dislike SVN, but it doesn't have any compelling features that make me want to stay with it. SVN is good but not great, and there's one usage pattern for SVN that works but is limiting. SVN isn't hurting Parrot, but it's not lifting us up to the next level either.
Tuesday, October 13, 2009
Matrixy: Moving Forward
The world of Parrot is an ever-moving target, but my poor compiler project Matrixy has been laying fallow for several months. Matrixy, for those who haven't seen me write about it before, is an implementation of the M language (MATLAB/Octave, not the new, weird, .NET language). MATLAB/Octave is the standard language of choice for many branches of science and engineering. I have never seen another language, except maybe R, which is so catered to the task of design and simulation, and it has some of the best integrated mathematics support I have ever seen.
Matrixy History
I started what is now called Matrixy about two years ago now when I was still in grad school. Part of my thesis involved writing an assembler in MATLAB for a new processor architecture I was designing in the visual programming component Simulink. Since I was just getting involved in Parrot at the time (and was reading the classic Dragon Book cover-to-cover in my leisure time), I decided an M compiler would be a great project to start. I put it on hold during GSOC and immediately thereafter when I was still burried knee-deep in Parrot core internals work. Luckily the idea was rescued by a guy named Blair who set up a project on googlecode and together we made a lot of progress implementing the syntax and semantics of the core language. Part of the standard M package is a huge list of built-in functions, something we didn't even attempt to reproduce.
Blair moved on to other projects, and I haven't turned back to Matrixy in months. It's sat completely dormant for months now, and needs a breath of life pumped into it. I can't think of a better time to do that either: With PCC refactors landing soon (I hope) and Plumage taking off, there is plenty of opportunity to get Matrixy up and running again. Here's a list of things I would like to do with the project, and I am looking for helpers and volunteers who would like to get involved.
Linear Algebra Libraries
Integral to M is comprehensive linear algebra support. This is what makes it such a great tool for engineers to use. Implementing these features, we've written bindings for Parrot to the CLAPACK and CBLAS linear algebra libraries. With Plumage quickly growing into a great ecosystem project, I would like to separate out the CBLAS and CLAPACK libraries into a separate "Linear Algebra Pack" to be dowloaded through Plumage.
This is going to require some work, however. CBLAS and CLAPACK have several functions with very exotic function signatures, and currently we would need to recompile Parrot to include them. Once Parrot has a proper NCI call frame builder, we don't need to worry about that.
Separating our libraries out into separate projects is going to help other languages and projects on Parrot who want to use them. However, it's going to require adding non-local dependencies to Matrixy's makefile. Small price to pay for the greater good.
Proper Matrix Data Types
One thing that M requires is a native matrix data type. We've managed to get along so far with an ad hoc system of nested ResizablePMCArray objects, but that's a terrible (and slow!) solution. Better yet would be to write up a good set of dedicated PMC types that implement a 2-D floating point matrix or vector. Having that PMC type support a sparse mode, or having a separate sparce array type would be fantastic too. If we included these PMC types with the "Linear Algebra Pack" that I talked about above, we would be able to quickly integrate robust linear algebra support in any language or project running on top of Parrot.
Imagine that in a few months time you could be using Perl6 or PHP or TCL to manipulate numerical matrices and performing complex linear algebra on them at blinding native code speeds!
Make Matrixy Installable
Matrixy currently doesn't work with an installable Parrot. In fact, Matrixy isn't really installable by itself either. We need to fix these things.
Matrixy needs to work against an installed Parrot so we can start properly tracking point releases instead of SVN head. Of course I always expect there to be exceptions to the rule, but it's a good policy to get into the swing of.
Matrixy also needs to be able to be packaged up and installed, especially through Plumage.
Move Matrixy to Github
Actually, this is something I think I can do on my own. I don't have any problem with Googlecode, but I feel the sea change pulling us towards Git and I would like to host at least one project through Git so I can start getting good with the tool. Github seems like a great place and I really like the social atmosphere.
Conclusion
Obviously there is a lot of primary development to be done too. We're a long way away from even having the complete syntax working, much less the semantics and the gigantic runtime library. However, with a few small changes Matrixy could be well along it's way to being not only a first class compiler project on Parrot, but a contributing force to other language projects as well.
If you have any knowledge about working with an installed Parrot, or working with Plumage, I would love to hear from you! Once I get things moved up to Github, I'll have plenty of commit bits to hand out to interested contributors.
Matrixy History
I started what is now called Matrixy about two years ago now when I was still in grad school. Part of my thesis involved writing an assembler in MATLAB for a new processor architecture I was designing in the visual programming component Simulink. Since I was just getting involved in Parrot at the time (and was reading the classic Dragon Book cover-to-cover in my leisure time), I decided an M compiler would be a great project to start. I put it on hold during GSOC and immediately thereafter when I was still burried knee-deep in Parrot core internals work. Luckily the idea was rescued by a guy named Blair who set up a project on googlecode and together we made a lot of progress implementing the syntax and semantics of the core language. Part of the standard M package is a huge list of built-in functions, something we didn't even attempt to reproduce.
Blair moved on to other projects, and I haven't turned back to Matrixy in months. It's sat completely dormant for months now, and needs a breath of life pumped into it. I can't think of a better time to do that either: With PCC refactors landing soon (I hope) and Plumage taking off, there is plenty of opportunity to get Matrixy up and running again. Here's a list of things I would like to do with the project, and I am looking for helpers and volunteers who would like to get involved.
Linear Algebra Libraries
Integral to M is comprehensive linear algebra support. This is what makes it such a great tool for engineers to use. Implementing these features, we've written bindings for Parrot to the CLAPACK and CBLAS linear algebra libraries. With Plumage quickly growing into a great ecosystem project, I would like to separate out the CBLAS and CLAPACK libraries into a separate "Linear Algebra Pack" to be dowloaded through Plumage.
This is going to require some work, however. CBLAS and CLAPACK have several functions with very exotic function signatures, and currently we would need to recompile Parrot to include them. Once Parrot has a proper NCI call frame builder, we don't need to worry about that.
Separating our libraries out into separate projects is going to help other languages and projects on Parrot who want to use them. However, it's going to require adding non-local dependencies to Matrixy's makefile. Small price to pay for the greater good.
Proper Matrix Data Types
One thing that M requires is a native matrix data type. We've managed to get along so far with an ad hoc system of nested ResizablePMCArray objects, but that's a terrible (and slow!) solution. Better yet would be to write up a good set of dedicated PMC types that implement a 2-D floating point matrix or vector. Having that PMC type support a sparse mode, or having a separate sparce array type would be fantastic too. If we included these PMC types with the "Linear Algebra Pack" that I talked about above, we would be able to quickly integrate robust linear algebra support in any language or project running on top of Parrot.
Imagine that in a few months time you could be using Perl6 or PHP or TCL to manipulate numerical matrices and performing complex linear algebra on them at blinding native code speeds!
Make Matrixy Installable
Matrixy currently doesn't work with an installable Parrot. In fact, Matrixy isn't really installable by itself either. We need to fix these things.
Matrixy needs to work against an installed Parrot so we can start properly tracking point releases instead of SVN head. Of course I always expect there to be exceptions to the rule, but it's a good policy to get into the swing of.
Matrixy also needs to be able to be packaged up and installed, especially through Plumage.
Move Matrixy to Github
Actually, this is something I think I can do on my own. I don't have any problem with Googlecode, but I feel the sea change pulling us towards Git and I would like to host at least one project through Git so I can start getting good with the tool. Github seems like a great place and I really like the social atmosphere.
Conclusion
Obviously there is a lot of primary development to be done too. We're a long way away from even having the complete syntax working, much less the semantics and the gigantic runtime library. However, with a few small changes Matrixy could be well along it's way to being not only a first class compiler project on Parrot, but a contributing force to other language projects as well.
If you have any knowledge about working with an installed Parrot, or working with Plumage, I would love to hear from you! Once I get things moved up to Github, I'll have plenty of commit bits to hand out to interested contributors.
Thursday, September 24, 2009
Version Control Systems
After a discussion earlier this week, I created a poll on parrot.org about version control systems. The question is simple: Which VCS would you prefer Parrot to use? Of course, it's just a non-binding strawpoll, but if there is overwhelming support for one option over the others it might inform and even motivate such a decision later.
My personal opinion is that I would like to migrate Parrot from SVN to Git.
Here's some background: I've never really used Git and don't know a lot about using it. Further, all my distributed development work, on Parrot and on other smaller projects has always used SVN. A few months ago I won a major victory at work when I convinced my boss to use SVN for all our in-house development. I setup and actively maintain the SVN server at work, teach my coworkers to use it and use it better, and am happy with the results overall.
pmichaud said it best the other day when I asked about it on IRC:
SVN is great for some things. It's centralized, and although that brings a certain amount of rigidity it also brings some assurances and simplifications. Sure you can use Git in a way similar to SVN, but you don't need to and that option can be scary for some people. Sometimes you want one repository, strict revision numbering, and an unambiguous current state to the code. Sometimes you want to know that all your code is safe on a redundant SVN server, and people don't have "checked in" changes on their local machines that aren't being included in the nightly tape backups. There are plenty of good reasons for workplaces to use SVN, and I think it's a great choice for many of those situations. It's a particular solution to a particular problem, and it's perfect for some situations.
At work we moved to SVN because I could make arguments, impassioned and influential, that SVN was better then our previous system (externally-hosted VSS). And my arguments were good and true. The migration was not completely pain-free, there are some issues that our team is still working out months after the fact. For instance, the mechanics of branching, tagging, and merging is still foreign to some people who have never had to deal with them before. Of course, having problems using powerful new tools effectively is far better in my opinion then not having those tools at all. We went from a system with absolutely zero branches and tags to having dozens of each. We started with a culture having almost zero code sharing or collaborations between developers, and are gradually learning to embrace these ideas. SVN is the learning tool that makes these new ideas possible.
Git is a little more complicated, if only at the conceptual level. When I first started trying to learn Git I was bombarded by all sorts of terminology, long pages about philosophy, and page after page of very pretty charts and graphs. It was overwhelming and I wrote it off as being more hassle then it was worth. However, since my initial forays into the topic I've learned a lot more about it and have become much more comfortable with the ideas. I find use cases almost every single day where I have problems in SVN that could be easily and elegantly solved if I were using Git. Sometimes I want to make a branch where I can just make a few test commits. If those little "commits" turn into a huge SVN patch, it becomes much less easy to review and apply.
In SVN I follow a few personal rules that I've picked up gradually: Don't make multiple simultaneous branches that touch the same subsystem. Don't rename files in a branch. In fact, try to do as little file renaming as possible. Don't sync up branches with trunk too frequently. Don't let branches live too long without merging. Keep track of all your branching/merging revisions. Very very carefully examine merge diffs, especially if there are any conflicts at all, to make sure things are resolving in a sane way. When making branches, I have a script I follow and I don't go off the script. If too many problems pop up, I'll create a second branch or even abandon branches entirely and use a flat diff instead. It's like any tool, you have to know when to use it and how to use it properly when you do.
So why do I like Git? First off, it's flashy and new. As Austin Hastings mentioned on IRC:
People worry about the learning curve for Git, or the time it's going to take to get our developers working with the new tool. Of course, you rarely ever hear people complain about the learning curve for SVN: It's not just the time it takes to learn the simple commands like commit, checkout and update, but the time it takes to learn about all the nuances and best practices. SVN makes it exceptionally easy in some cases to dig yourself into a hole that is difficult to climb out of. From what I have seen of Git, this same thing is not true. The easy cases stay easy, and the hardest cases become possible.
Another great quote from pmichaud on IRC illustrates this point:
In summary, here are my arguments for moving to Git: It represents an improvement in a critical development tool that will increase productivity for our developers. Upgrading tools and methodologies is a natural and healthy thing for projects to do. It keeps best practices current, keeps developers productive and happy, and keeps everything moving forward. Git is not the be-all end-all of version control, but being in a regular habit of upgrading and improving our toolset is a good thing for Parrot or any software development team. SVN is a great tool in certain cases, and has lots of merits. Supporting a large distributed development team working in large numbers of branches like we have been doing recently in Parrot is not one of those cases though.
Note: Parrot foundation members should be able to vote in the straw poll on the website. If you are a member but don't have the proper permissions on the website, talk to myself or one of the other admins to make sure you get properly flagged so you can participate. Keep in mind that this is only an informal straw poll and that the results of it are not binding in any way. It's just being used as a tool to measure the general opinions of the development community.
My personal opinion is that I would like to migrate Parrot from SVN to Git.
Here's some background: I've never really used Git and don't know a lot about using it. Further, all my distributed development work, on Parrot and on other smaller projects has always used SVN. A few months ago I won a major victory at work when I convinced my boss to use SVN for all our in-house development. I setup and actively maintain the SVN server at work, teach my coworkers to use it and use it better, and am happy with the results overall.
pmichaud said it best the other day when I asked about it on IRC:
When rakudo needed to switch repositories earlier in the year, I put out a call to see whether people thought we should stick with svn versus moving to git. I got a lot of feedback. However, the clinching argument is that *nobody* argued in favor of SVN based on it's merits of being easier to use or having superior technology. The only reason that anybody had with staying with SVN was because that was what we had been using previously. So if it comes down to "influential arguments" as to making one choice versus another, I'd like to see informed reasons for staying with SVN. We clearly have a lot of Parrot developers who can give informed reasons for moving to GitIn the back of my head I am reminded of those grizzled old programmers who don't understand why anybody would ever write anything in a language besides Fortran or Cobol. I remember an argument I read once, back in the days when I was still young and stupid enough to participate in programming language flame wars on anonymous internet message boards, that said: "Perl is written in C, so anything Perl can do C can do but faster". Sure it's faster if you don't count all the extra development and debugging time, if you take the time to properly refactor and optimize your algorithms, and if you aren't worried about problems like leaking memory or security issues. But I digress. C, Fortran, Cobol, and Perl all have their uses (C is great for writing infrastructure like Parrot, Perl is great for most other things, and Fortran and Cobol are great for being rewritten in C or Perl).
SVN is great for some things. It's centralized, and although that brings a certain amount of rigidity it also brings some assurances and simplifications. Sure you can use Git in a way similar to SVN, but you don't need to and that option can be scary for some people. Sometimes you want one repository, strict revision numbering, and an unambiguous current state to the code. Sometimes you want to know that all your code is safe on a redundant SVN server, and people don't have "checked in" changes on their local machines that aren't being included in the nightly tape backups. There are plenty of good reasons for workplaces to use SVN, and I think it's a great choice for many of those situations. It's a particular solution to a particular problem, and it's perfect for some situations.
At work we moved to SVN because I could make arguments, impassioned and influential, that SVN was better then our previous system (externally-hosted VSS). And my arguments were good and true. The migration was not completely pain-free, there are some issues that our team is still working out months after the fact. For instance, the mechanics of branching, tagging, and merging is still foreign to some people who have never had to deal with them before. Of course, having problems using powerful new tools effectively is far better in my opinion then not having those tools at all. We went from a system with absolutely zero branches and tags to having dozens of each. We started with a culture having almost zero code sharing or collaborations between developers, and are gradually learning to embrace these ideas. SVN is the learning tool that makes these new ideas possible.
Git is a little more complicated, if only at the conceptual level. When I first started trying to learn Git I was bombarded by all sorts of terminology, long pages about philosophy, and page after page of very pretty charts and graphs. It was overwhelming and I wrote it off as being more hassle then it was worth. However, since my initial forays into the topic I've learned a lot more about it and have become much more comfortable with the ideas. I find use cases almost every single day where I have problems in SVN that could be easily and elegantly solved if I were using Git. Sometimes I want to make a branch where I can just make a few test commits. If those little "commits" turn into a huge SVN patch, it becomes much less easy to review and apply.
In SVN I follow a few personal rules that I've picked up gradually: Don't make multiple simultaneous branches that touch the same subsystem. Don't rename files in a branch. In fact, try to do as little file renaming as possible. Don't sync up branches with trunk too frequently. Don't let branches live too long without merging. Keep track of all your branching/merging revisions. Very very carefully examine merge diffs, especially if there are any conflicts at all, to make sure things are resolving in a sane way. When making branches, I have a script I follow and I don't go off the script. If too many problems pop up, I'll create a second branch or even abandon branches entirely and use a flat diff instead. It's like any tool, you have to know when to use it and how to use it properly when you do.
So why do I like Git? First off, it's flashy and new. As Austin Hastings mentioned on IRC:
And FWIW, switching to a new VC system is always a fashion show. You should expect mad enthusiasm for whatever new thing comes along after git, too.And he's right, to a point. New tools are good if they fix the problems present in old tools, add new features, and make life easier. Fewer problems and more features always make people excited, and for good reason. Nobody is going to claim that SVN is the pinnacle of VCS technology. Git is an improvement over SVN, and there will be systems in the future that improve upon Git as well. It's the same exact way that we want programming language developers to move to Parrot instead of brewing their own interpreters from the ground-up: Parrot represents a better system that will be easier to use then the old method. We have things like PCT that makes compiler designer far easier then it would be even on other similarly-capable virtual machines. It's the same as how people switched to C++ 20 years ago, switched to Java 10 years ago, and switched to C# 2 years ago. You're never done learning, and new tools will always come along that make developers more productive.
People worry about the learning curve for Git, or the time it's going to take to get our developers working with the new tool. Of course, you rarely ever hear people complain about the learning curve for SVN: It's not just the time it takes to learn the simple commands like commit, checkout and update, but the time it takes to learn about all the nuances and best practices. SVN makes it exceptionally easy in some cases to dig yourself into a hole that is difficult to climb out of. From what I have seen of Git, this same thing is not true. The easy cases stay easy, and the hardest cases become possible.
Another great quote from pmichaud on IRC illustrates this point:
I think we have a significant number of parrot devs who have said that they find git merging much easier than svn. I don't know why we need more examples than that. Either that or we simply believe our developers have no clue about what they're talking about. afaik, none of the people who say "git merging is easier" are doing so based on speculation. It's all from hard experience in doing merges in both svn and git.I won't even claim that branching and merging is easier in Git. I've never done it. However, I have heard lots of other people say that and I am very optimistic that this is the case. If it makes the hard case less hard, that's really all I need to hear.
In summary, here are my arguments for moving to Git: It represents an improvement in a critical development tool that will increase productivity for our developers. Upgrading tools and methodologies is a natural and healthy thing for projects to do. It keeps best practices current, keeps developers productive and happy, and keeps everything moving forward. Git is not the be-all end-all of version control, but being in a regular habit of upgrading and improving our toolset is a good thing for Parrot or any software development team. SVN is a great tool in certain cases, and has lots of merits. Supporting a large distributed development team working in large numbers of branches like we have been doing recently in Parrot is not one of those cases though.
Note: Parrot foundation members should be able to vote in the straw poll on the website. If you are a member but don't have the proper permissions on the website, talk to myself or one of the other admins to make sure you get properly flagged so you can participate. Keep in mind that this is only an informal straw poll and that the results of it are not binding in any way. It's just being used as a tool to measure the general opinions of the development community.
Subscribe to:
Posts (Atom)
