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.

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.

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.

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