On Jan 20, 2009, at 10:11 PM, Joel Holdsworth wrote:
I just noticed that we have two "input devices" commands in File menu. Please whoever did this, decide which one we will use and delete the other!
In general, I would propose a "bus tomorrow" rule as a general guideline for committing stuff to our SVN:
Before committing, imagine you are hit by bus tomorrow and cannot
It seems like this project is really suffering from not having decent source control software, because this is exactly what branches were designed for - something which is a major PITA in SVN.
Actually branches are often a bigger PITA that not. Other than the low-level tech differences (where SVN vs. GIT really differ), the general workflow of many people adding new things to an existing codebase gets unruly. It's not as much an aspect of the tool, but is an aspect of the higher-level problem. I've see things come up over an over again (even with people who use SVN or Bzr or such) and some comes down to the longer something diverges, the more issues are encountered.
It really worries me that the inkscape SVN is such a free-for-all, leading to the situation that between releases, the quality of the code drops so low that it takes months to tidy it up again; and still there are many bugs released. If you had GIT or Bazaar or whatever, combined with a decent organization structure (allowing only a few people to apply patches to trunk), you'd see the quality of inkscape radically improve because people would be able to experiment and mess around without hosing the trunk.
That is what happens in general. And we have things in place to address that.
However, I think the higher level issue is the approach to development. We really could be considered an agile project, with all that goes along with that. Experiments *do* go off trunk for the most part, but actual work in progress does go in. That's perhaps a subtle difference, but one thing we work with.
Ken Schwaber's article "Get Ready for Scrum!" really sets things out well http://www.informit.com/articles/article.aspx?p=24027 (there are actually 8 pages there, not 7, so don't let it fool you into stopping early)
Wine is a good example of this working well - they are able to release every 2 weeks. Their code is beautifully tidy, they have very few bugs and regressions, and there's very little redundancy because a few people are keeping an eye on what's being put in.
Actually I would say that Wine is a good example of a completely different project with completely different needs and development management. Among other things it is merely implementing a fully specified system (perhaps not as well documented, but fully specified) with very precise constraints. That does lend it self more to a waterfall approach. Adding completely new features to a freeform tool is a different design flow.
Git is really helping us on the Lumiera project for exactly these reasons.
We've had people researching Git, Bzr and many other for some time now. Some are even using it now. However the issue is not so much on of the tool.
Also, different developers work different ways. Bulia, for example, is *very* good at thinking of something, going off and tuning it in his day-to-day-work, and then committing a magic all-in-one appearance. For myself, I work much better in a collaborative, iterative approach. Some also is that I am not an artist in my day work, so I don't get as much time to view things that way myself. The other is that I do talk things out with artists in our project, but more often they can't visualize the new approaches until they can get their hands on a first iteration.
In this case we did have new functionality, no breakage of old functionality, and something some people found useful. Bulia pointed out the main issue with possible confusion, and since that came to attention, it was something I tuned up and got going.
Far more than any source control change or change to contributors effective workflow, I believe we would gain from beefing up and having more people running our automated testing. *That* is a tool use that can bring major improvements. With Agile, XP and TDD, having good and expanding tests in place really pay off far more than source tool tweaks.