Group items tagged

Version control systems have traditionally required a lot of up-front planning followed by constant interaction to get changes to the right place at the right time and in the right order. And woe unto thee if a rule is broken somewhere along the way, or you change your mind about something, or you just want to fix this one thing real quick before having to commit all the other crap in your working copy.

You can work on five separate logical changes in your working copy – without interacting with the VCS at all – and then build up a series of commits in one fell swoop. Or, you can take the opposite extreme and commit really frequently and mindlessly, returning later to rearrange commits, annotate log messages, squash commits together, tease them apart, or rip stuff out completely. It’s up to you, really. Git doesn’t have an opinion on the matter.

I’ve personally settled into a development style where coding and interacting with version control are distinctly separate activities. I no longer find myself constantly weaving in and out due to the finicky workflow rules demanded by the VCS. When I’m coding, I’m coding. Period. Version control - out of my head. When I feel the need to organize code into logical pieces and write about it, I switch into version control mode and go at it. I’m not saying this is the Right Way to use Git: in the end, it all goes to the same place. I’m saying that this is the way I seem naturally inclined to develop software, and Git is the first VCS I’ve used that accommodates the style.

that's not the whole picture. First and foremost you forgot the disconnected part. You can't commit to Subversion unless you can reach the repository, which is often in a server over the Internet. Also, each developer isn't restricted to one branch. He very often has a lot of them. Right now I have 28 separate branches of Qt in my workstation: they range from previous stable releases of Qt (to test regressions and fixes with) to branches I created to start working on fixing tasks to research projects.

And that's just my private branches. When I am collaborating with other people in projects, I have more branches. For one project right now in Qt, we are tracking 4 or 5 different branches, each with a different "theme": optimisations, new features, animations, etc. And there's an extra branch which is the merger of all those "theme branches", so that we can get a feel of what it will be when it's done.

Finally, you're also forgetting the ability to undo, redo, and modify your work. Once you commit to Subversion, it's there for life. Removing something from the repository means dumping and reloading it. With a Git, you can undo your commits, change them, squash them together without problems. (You can do that after you've published them, technically, but you shouldn't)

The centralized development system in Subversion's trunk doesn't support team-based development very well

Furthermore we're still looking for more contributors, so lowering the barrier for entry is another important concern.

We will have to allow for more diversity and we must be able to accommodate individual workflows.

I certainly agree that almost any project will want a "central" repository in the sense that you want to have one canonical default source base that people think of as the "primary" source base. But that should not be a *technical* distinction, it should be a *social* one, if you see what I mean.

Release management: you often want the central "development" repository to be totally separate from the release management tree. Yes, you approximate that with branches

Yes, you can branch in a truly centralized model too, but it's generally a "big issue"

With that I mean that in KWord I tend to work on a feature by first writing a unit test and committing that. After that I start to implement the feature until it actually passes the unit test and after that I add UIs etc etc etc. In other words; it takes me a week with 30 commits before I finish this new feature. And finish naturally doesn't mean bug-free. During this time I will surely find bugs in other pieces of code, or simple little features to add there. I commit those separately. All the above goes into one git tree and depending on how much I work with others on the features I publish that git tree. But the small fixes will be committed to the 'release' tree (aka svn) as soon as possible. At the end of the week when my feature is 'done' I will also push that upto the release tree. So, what IMOHO you, as a svn user, will end up with is the trunk that doesn't have half finished features that mess everything up. You will still see the current development (mostly) but not the dirty work-in-progress-excuse-the-mess versions. As an example; in Krita we have this excellent GSoC project for color mixing, the author programs in trunk and thus commits everything there. We have had a couple of times when his commits made it hard for others to try out his work. I.e. it was quite broken. I'm all for experimentation so I'm not complaining. But at the same time I do see it as a great opportunity for Git where I can imagine him committing his work-in-progress that is known to create regressions and publish that for other interrested people to see. And only after a week of hacking commit his updated version to the release tree so everyone can enjoy it. leaving the release tree free from major regressions.

And I believe that Git actually helps by allowing others to see a more representative version of the software instead of one that is constantly in flux.

All the workflows you are used to are still there, there just are more workflow possibilities and thus more ways to get productive. So, I really don't think it is in any way an extra barrier. It actually tears down several barriers.