dvcs-vs-vcs

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)

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).

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.

I think it is much improved over the early drafts, and I don't think it's a horrible licence. I just don't think it's the same kind of 'great' licence that the GPLv2 is.So in the absence of the GPLv2, I could see myself using the GPLv3. But since I have a better choice, why should I?That said, I try to always be pragmatic, and the fact that I think the GPLv3 is not as good a licence as the GPLv2 is not a 'black and white' question. It's a balancing act. And if there are other advantages to the GPLv3, maybe those other advantages would be big enough to tilt the balance in favour of the GPLv3.Quite frankly, I don't really see any, but if Solaris really is to be released under the GPLv3, maybe the advantage of avoiding unnecessary non-compatible licence issues could be enough of an advantage that it might be worth trying to re-license the Linux kernel under the GPLv3 too.Don't get me wrong -- I think it's unlikely. But I do want to make it clear that I'm not a licence bigot, per se. I think the GPLv2 is clearly the better licence, but licences aren't everything.After all, I use a lot of programs that are under other licences. I might not put a project I start myself under the BSD (or the X11-MIT) licence, but I think it's a great licence, and for other projects it may well be the right one.

I like making strong statements, because I find the discussion interesting. In other words, I actually tend to 'like' arguing. Not mindlessly, but I certainly tend to prefer the discussion a bit more heated, and not just entirely platonic.And making strong arguments occasionally ends up resulting in a very valid rebuttal, and then I'll happily say: "Oh, ok, you're right."But no, that didn't happen on SVN/CVS. I suspect a lot of people really don't much like CVS, so I didn't really even expect anybody to argue that CVS was really anything but a legacy system. And while I've gotten a few people who argued that I shouldn't have been quite so impolite against SVN (and hey, that's fair -- I'm really not a very polite person!), I don't think anybody actually argued that SVN was 'good'.SVN is, I think, a classic case of 'good enough'. It's what people are used to, and it's 'good enough' to be used fairly widely, but it's good enough in exactly the sense DOS and Windows were 'good enough'. Not great technology, just very widely available, and it works well enough for people and looks familiar enough that people use it. But very few people are 'proud' of it, or excited about it.Git, on the other hand, has some of the 'UNIX philosophy' behind it. Not that it is about UNIX, per se, but like original UNIX, it had a fundamental idea behind it. For UNIX, the underlying philosophy was/is that, "Everything is a file." For git, it's, Everything is just an object in the content-addressable database."

I think there's both a licence issue, and a community and personality issue. The BSD licences always encouraged forking, but also meant that if somebody gets really successful and makes a commercial fork, you cannot necessarily join back. And so even if that doesn't actually happen (and it did, in the BSD cases -- with BSDi), people can't really 'trust' each other as much.In contrast, the GPLv2 also encourages forking, but it not only encourages the branching off part, it also encourages (and 'requires') the ability to merge back again. So now you have a whole new level of trust: you 'know' that everybody involved will be bound by the licence, and won't try to take advantage of you.So I see the GPLv2 as the licence that allows people the maximum possible freedom within the requirement that you can always join back together again from either side. Nobody can stop you from taking the improvements to the source code.