Group items tagged

It decouples the notion of checkpointing from publishing. In Subversion, those are the same thing

Git lets developers experiment with the whole of a project, without worrying about breaking things or losing work

With Git running locally, developers push commits whenever they feel like and can fork and experiment to their hearts’ content. Those changes won't bother anyone “until you share [them],” said Vilain. “You share at the end of the day, after a day's work, when you've gone over the code a bit more.”

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)

You see, branches and tags in CVS are different things. But in subversion, they are the same - they are just copies of the trunk into one of those directories. In CVS, these events are temporal... that is, they affect a file at a given point in time. In Subversion, while they still apply to a particular version of a file, branches and tags are spatial... that is, they exist as copies of the trunk, just copied into a specially designated place. This 'branches' and 'tags' convention in subversion is actually limiting, and somewhat false. Since they are really the same thing, I can modify the contents of a 'tag', which is impossible in CVS. I have come to believe that while this convention is useful for projects converted from CVS, it is misleading, limiting, and harmful for new projects. I want a new convention

As long as I am coming up with a new convention, what other things might I want to address? First, I like to have a place 'close to the code' where management documents like requirements, meeting minutes, and the like can be stored, but these kinds of things rarely (if ever) need to be branched. I also like Maven's convention that allows for directories of different kinds of source to be part of the same project. Taking all this into account, here is my new convention: /project /code /head /rails /java /versions /design /management

Gone are the 'branches' and 'tags' directories, in favor of a single 'versions' directory that should always contain copies of the head with meaningful version names.

And then git... If I look at what happens in the linux kernel development community, I see the best developers being permanently busy with merging, merging, merging and merging and very little else. And, actually, a scheme where we only seldom integrate, where every developer at one, infrequent, moment publishes their branch for merging sounds like a recipe for integration hell, no matter how developer-friendly and good at branching and merging a tool might be.

The Linux kernel development process is not very similar to KDE's of course. The overhead of what's going in is higher, it's quite formal and bound to specific persons that decide it all. KDE is quite different in that it's team-based, so potentially making it easier to share code in those teams and merge it upstream as it becomes interesting for others until finally bugs have been shaken out and it's ready to go into trunk.

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.

Distributed development needs a network of trust. For small projects, things are very simple: There's (say) one person, and that person reviews all incoming changes, and publishes (pushes) the result to a known location. Users need only trust that single point of distribution. If someone else publishes a different version of the same project, it's the user's problem to trust that someone else. For a larger project things become more involved. It starts by a single point of distribution, which only one or few people have push access to. Those people must be trustworthy. Let's call them BD. (Of course, nobody is forced to trust them.) But since it cannot be expected that they can review all incoming changes, they need other people, "lieutenants", whom they in turn trust. That is, BD will pull changes from the lieutenants without detailed review and push them out to the single point of distribution. The lieutenants themselves are possibly again backed by "major contributors" whom they trust. (At this point the fields of responsibility are likely small enough that incoming changes can be reviews in detail by the lieutenant or major contributors.)

At the infrastructure level, you need means that the chains of trust cannot be broken. At the lowest level, git provides a chain of trust by the SHA1 signatures. At a higher level, trust must be implemented such that each person can change (basically) only his own repository. For this reason, it is good that in your earlier proposal access rights to certain repositories were very limited. BD and lieutenants will only pull from such restricted repositories. Major contributors will review all incoming changes and push to their own trustable repositories and ask the lieutenants to propagate the changes upstream. In this context, "incoming" will mean mostly changes pushed to the publically accessible repository tree by random contributors, and the users' repositories. To come back to your example: I will trust *you*. And will blindly pull from *your* repository, no matter whose name the commit carries.

The biggest difference is that with git (or any other SCM that can _actually_ merge) multiple people can have their branches and merge with each other and after merging "annotate" and the like still work. That is not the case with svn and svnmerge.

Well, it is working in the sense that we can use git without disrupting things for those who wish to continue working with svn. No, it isn't optimal for those who wish to completely convert to using git, but it is better than no git at all I guess.

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.

Another option is to look at git-svnserver which would allow a git repository backbone, but could talk svn over the wire which these tools could use...

Btw, to see this in another light: as an example of a git tree that merges those same branches, but *before* they are ready, just look at the -mm tree. Now, Andrew actually ends up exposing the end result not as a git tree, but as patches, but what he actually *does* is to: - get my git tree - merge in about 30-40 other git trees from other developers (not all of which necessarily have actual development on them at any particular time) - then merge in his own patch list - expose it all as the -mm patch series So this is an example of how you actually have a totally separate, and still fairly central (the -mm tree is certainly now unknown outside of the core developer circles) tree, and where git is a big part in making a central "experimental" tree that is separate from my own central "development" tree. Also, it's an example of why centralization is bad: different people and entities have different intents. You could *not* reasonably do something like this with a centralized SCM like SVN.

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"

Major reason is that branching is easy but merging is a pain

Subversion has no History-aware merge capability, forcing its users to manually track exactly which revisions have been merged between branches making it error-prone.

No way to push changes to another user (without submitting to the Central Server).