No, you don’t understand. It’s only the “official maintainer releases” that are centralized. i.e. only the official maintainers can create them. This is a tautology.

On the other hand, the actual development of the code *was* decentralized because different developers were able to ‘sync up’ without an “official” release. You could do this with a central server, but it creates bottlenecks and artificial class distinctions (see below.)

“But really, this is nothing Subversion cannot do with almost as little effort.”

You are proposing sweeping changes to SVN. You do a lot of hand-waving on exactly how it will work, so it’s hard to comment.

First, you are creating a lot of central bandwidth and storage for trees that may or may not ever pan out.

But real distributed source control management systems have the feature that *ANYONE* can be a maintainer and make their own releases. (I’ll admit that’s not useful in a corporate setting, but we’re talking Open Source.)

In the central SVN model, the core developers create “2nd class developers” who can never be maintainers in their own right. Nobody can collaborate except at the whim of the core developers. If the core developers get stingy with the commit bit (or “branch bit” in your scenario), then the project stagnates. (See the XFree86/Xorg fiasco.)

“Official maintainer” is a *social* designation, not a technical one. Therefore, you can declare yourself the “official maintainer” of Loren’s repo. You shouldn’t be at the mercy of someone else to host it.

Linus has a kernel tree, but he will be the first to tell you that his tree isn’t special at all. (In fact, historically, almost no distros shipped his tree.) Linus only gets to decide what’s in his tree. Others (Andrew Morton, Alan Cox, the PowerPC arch guy, the SCSI subsystem maintainer) get to decide what’s in their trees. If the PowerPC guy wants to sync with my tree, he shouldn’t need anyone’s permission, and I shouldn’t need an account on a central server.

It’s ironic that the SVN maintainers may look at your suggestion and decide “no, we’re not going in that direction”, and you’ll probably wished you had a distributed SCM so you could work on your idea without their permission (and without a major fork like EMACS/EGCS/etc).

> Yeah, because, fuck man, I live half my life in an airplane.

It doesn’t need to be airplane; it can be train, bus or tram. It is enough if you don’t have network connection. Or your central server can be down, or the network is congested and it is responding slowly.

Off-line commits is a nice feature to have.

Rewriting (changing) *published* history is a big no-no. In centralized SCM commiting means publishing. In distributed SCM publishing (push) is separated from comitting changes. So IMHO rewriting history has sense *only* for distributed version control systems, regardless of technical issues / implementation details.

As to “partial checkout” (ability to checkout just 3 relevant files out of 5000): it plays merry hell with whole-tree (whole-project) commits, and encourages gigantic monolithic repositories. As to Git having no interest in this feature: from some time Git has submodules support, which is proper way of dividing project; it is something akin to svn:externals “done right” ;-). “Partial checkouts” is often requested feature, and from what I can see Nguyen Thai Ngoc Duy are planning to implement it.

Subversion has just too many issues; I wouldn’t enumerate them here. And Git can be used also in centralized fashion, as centralized SCM.

One more thing: as Linus said in his Google Tech Talk, for projects with very large community you want to have “network of trust”, because maintainer does not scale. So IMHO DSCM is better for such projects. For single developer project DSCM are mich easier to set-up than centralized SCMs; it is just ” init” in top dir of your project. So…

Administrating your repository and editing previous changesets does not inherently require a distributed system. That’s purely up to the implementation details of the SCM you’re using. If anything, shame on Subversion for not adding these features- but they *can* exist without changing workflow.

Like I said before, I admit that Git has great *technical* advantages over Subversion. I can understand why that has cause people to start moving away from svn– heck, I’m doing it myself. However, most of what I heard up until now has not been anything that is completely out of the scope of Subversion’s work model. I still won’t completely abandon ship until the SVN community/devs make it clear that they will not attempt to improve the places where Git completely destroys them.

Subversion has its own advantages, they just don’t lie in the “technical” end, which everyone here is focusing on. It’s not about the brilliance of uber-unique SHA1 hashes, amazing tree-like filesystems and seamless branching/merging, but rather about simplifying workflow from the non-technical end. For instance, being able to check out just 3 relevant files in a repository of 5000 has enormous advantages, and this is something Git has no interest in from what I know.

How many times you have patch ready to send in your email client / last review before sending in your editor to notice a bug in a commit, or a typo in a commit message? Or perhaps you decided that documentation update should go into the same commit? “git commit –amend” is your friend.

Or perhaps when creating a series of commit (clean history, better review, bisectability) introducing some new feature, and in the middle of series you have noticed that with some change to infrastructure introducing this feature would be mich easier; cahnge which should go at the beginning of series. Or noticed a bug in an earlier commit? Or decided that the change had grown too much and commit should be split? “git rebase –interactive”, or cherry-pick, or StGit / Guilt is your friend.

Of course this makes sense only if you can have private development, in short only for distributed version control system.

—-
@Loren Segal: “everybody knows where to find your changesets”

With Git, or any other DSCM you can always have central publishing repo, like e.g. Linus tree on kernel.org is authoritative source to “get changesets”.

“Permissions” and “convincing” in Subversion repositories are merely a configuration issue, though; with proper write access already there this is a non-issue, and with little infrastructure you can automate branch creation / setting up write access to anonymous users. Yes, it’s a little more awkward just because it’s not natively supported, but the benefit is that everybody knows where to find your changesets.

But really, neither of those are acceptable solutions because, either way, you’re taking away time and adding unneeded complexity for such a simple task.

The biggest problem with SVN is, when it comes to branching, having to have the admins create a branch for you and all the work on your end to convince them to do so for you and on their end actually evaluating your request and performing the necessary action. That’s time wasted for two people, not just one…

Yeah, because, fuck man, I live half my life in an airplane….

With git I cd into a directory, init the repository do some coding. Check it in. Done. With SVN I have to have the repo in one place, them import into it, then check out, then code, then commit. I end up with two sets of files for the one project. I found that annoying.

Git makes it so easy that I tend to use it on even smaller projects.

Also, I really think the cheap branching shouldn’t be underrated. It has really changed the way I develop. I tend to keep related changes in their own branches, which makes committing much easier and lets me switch between tasks easily, without getting confused over which files belong to which change.

Concerning merb-core as an example of distributed SCM; it is not analogous to submitting a patch. When you do a git pull you’re merging the _history_ of two separate but related repositories.

This gives an amazing amount of flexibility. It’s possible for a contributor to make large breaking changes to code, while still checking them into their own repo. These changes can then later be merged into main repo, along with the associated history.

Finally, pulling from a remote repository is heaps better than applying patches and checking in changes IMO. A minor thing to be sure, but I’ve always found patching annoying.