7 ms·

Some of this is really interesting, other parts not so much. Versioning directories, pluggable storage layers, decentralized databases...these are interesting,

by gecko 16y ago

Some of this is really interesting, other parts not so much. Versioning directories, pluggable storage layers, decentralized databases...these are interesting, but have been tried, and have not thus far proved compelling. Thus far, I have not seen projects move to Bazaar or Monotone because they were fed-up with Git and Mercurial not versioning directories, nor have I heard of people picking Mercurial or Subversion because of their pluggable storage systems, nor do I see people choosing Fossil and Monotone because they have distributed databases. It's not that these aren't good features--some of them, like properly handling directories and renames, are (IMVHO) definite improvements over Git and Mercurial--but rather, they are not by themselves enough to make people switch what they're using. The real kicker for me is simply the license. All of the major DVCS players right now are GPL licensed. While Git's been pretty accepting of non-GPL compatible implementations (e.g., JGit, Dulwich), the Mercurial team has indicated that it would view any such project in a very dim light, and I can't conceive of anyone wanting to tempt the FSF by trying that kind of thing with Bazaar. Suddenly having a well-implemented closed-source-friendly DVCS could very easily result in a very sharp and immediate uptake among tool companies. This could completely change the game for corporate shops.

bch 16y ago
I don't know what qualifies as a "major DVCS player", but fossil is BSD licensed: http://methodlogic.net/BSDFossil.html http://methodlogic.net/BSDFossil.html
- gecko 16y ago
  I'm actually far more interested in Fossil since it became BSD-licensed, but it's not nearly as widely used as the other three. The biggest projects I know of that use Fossil are SQLite, Lamson, Librelist, and Fossil (natch). Git's major projects are things like the Linux kernel, X, and Rails; Mercurial's include Firefox, OpenJDK, and Xen; and Bazaar's users include Emacs and MySQL. All three of those also have large commercial hosting options that are pretty heavily used (e.g., GitHub, Gitorious, Google Code, Bitbucket, Kiln, Launchpad), whereas Fossil currently lacks anything similar. I'm not saying Fossil is bad for not being widely used; just that it's definitely not yet as popular as Git, Hg, and Bzr.
  - bch 16y ago
    No question it's not as popular. A few folks (myself included) are working on using it for the NetBSD src, though, fwiw. IF we get that up/running and blessed (by NetBSD, who are on search for CVS alternatives), it'd a nice feather in the hat for fossil.
  - tzs 16y ago
    Emacs is de jure using Bazaar, but is it using it de facto? I read somewhere (I think it was here on HN) that the Emacs developers were leaning toward Git, but RMS decided on Bazaar because that's the office GNU DVCS. The comment or article I read said that someone made a good Bazaar/Git bridge, and most of the active Emacs developers are actually using Git, and bridging to Bazaar when they want to push to or pull from the official repository.
    - avar 16y ago
      That's true to a large extent as far as I can tell. I've seen reports on emacs-devel of commits taking a couple of minutes, and of having merge issues you'd never encounter in Git. Bazaar wasn't chosen for Emacs for technical reasons, and they appear to be suffering the consequences of that.
tzs 16y ago
GPL covers code. If you take code from Git to write an alternative implementation, yours has to be GPL. However, if all you do is take the file formats and the over-the-wire protocol, and write original code, it can be under whatever license you want. That seems to be what most of the alternative Git implementations have done. The Git repository format is remarkably simple. I'm confident that if for some reason all copies of Git disappeared (binaries and source) and I needed to keep working with my existing Git repositories, I could cobble together something that would get me basic DVCS functionality in a couple of weeks. By basic functionality, I mean the ability to check out revisions, view history, make changes to the working copy, and commit them, and to tag and branch and merge. (Heck, it was only a couple of weeks or so for Linus to write the thing once he decided to go for it, and he didn't have the benefit of having a well-designed and documented repository format and wire protocol handed to him). Any decent programmer could do the same or better. Thus, I don't think Git being GPL is any significant barrier to adoption by people who need a good DVCS in a closed source project.
- gecko 16y ago
  While I am keenly aware that the GPL only covers code, some major contributors to the Mercurial team have indicated that they do not believe it would be possible to make a compatible implementation without consulting Mercurial's source code. Whether you agree or not is immaterial at that point; why bother doing so when it will at best alienate the community, and at worst end in a messy lawsuit?
  - tzs 16y ago
    I'd be curious why they think consulting the Mercurial source code would make the compatible implementation have to be GPL. Of course, rather than just go ahead and look and then write a compatible implementation from that knowledge, if I needed such a thing in a proprietary product, I'd pay a third party to read the Mercurial source and publish a specification of the file format, protocols, and rules for manipulating the repository (e.g., rules for locking things, and such). Then I'd implement from that specification. That should avoid any confrontation. There seem to be quite a few open source or free software projects where the developers think the license has more power than it really does. The reality is that all open source or free software licenses, even the more restrictive ones like GPL, will in fact let people do some things with one's software that one might not like. That's because these licenses are all based on relaxing the exclusive rights of the copyright holder. Unlike the typical proprietary software license, they aren't a mix of relaxing rights of the copyright holder and restricting rights of the user. Hence, if someone, including proprietary software companies, wishes to do something with with the code or the knowledge embedded therein, and what they want to do is something that doesn't require permission under copyright law, then they are free to do it. Personally, this is one of the reasons I have used the two clause BSD license for my recent works. People are going to find ways to legitimately do things I might not like. Instead of going with a restrictive free license like GPL and fantasizing that nothing bad can be done with my code and then being disappointed and pissed off when they do, better to just realize the price of giving users freedom is that they might do things I don't like, and not worry about it. Hence, BSD--the release and forget about it license. What I find kind of funny (hilarious, actually) is that the kind of protection that some developers wish to achieve IS actually available--via patents! The Mercurial developers can get what they want out of GPL by patenting their repository format and their protocols, and then making a free patent license available to implementations that use GPL.
tbrownaw 16y ago
> nor do I see people choosing Fossil and Monotone because they have distributed databases Monotone (and I believe Fossil) only version files/directories, and just happen to use SQLite as a local data store instead of rolling their own disk format. Veracity on the other hand, sounds like it allows simple databases as versioned objects in addition to directory trees. That's completely different and sounds very cool. I'm also not sure how necessary it is. For example monotone allows you to configure custom merger programs (intended for if you don't like KDiff3/Meld/etc) and to set a file attribute that prevents it from trying to use the internal line merger, so in theory you could just commit your database file (or disk image containing database files, or ...) and then write a custom merge program for them. But maybe what Veracity has will delta-compress better, and of course you'd get a merger that's already written.

by gecko 16y ago

bch 16y ago

I don't know what qualifies as a "major DVCS player", but fossil is BSD licensed: http://methodlogic.net/BSDFossil.html http://methodlogic.net/BSDFossil.html

gecko 16y ago
I'm actually far more interested in Fossil since it became BSD-licensed, but it's not nearly as widely used as the other three. The biggest projects I know of that use Fossil are SQLite, Lamson, Librelist, and Fossil (natch). Git's major projects are things like the Linux kernel, X, and Rails; Mercurial's include Firefox, OpenJDK, and Xen; and Bazaar's users include Emacs and MySQL. All three of those also have large commercial hosting options that are pretty heavily used (e.g., GitHub, Gitorious, Google Code, Bitbucket, Kiln, Launchpad), whereas Fossil currently lacks anything similar. I'm not saying Fossil is bad for not being widely used; just that it's definitely not yet as popular as Git, Hg, and Bzr.
- bch 16y ago
  No question it's not as popular. A few folks (myself included) are working on using it for the NetBSD src, though, fwiw. IF we get that up/running and blessed (by NetBSD, who are on search for CVS alternatives), it'd a nice feather in the hat for fossil.
- tzs 16y ago
  Emacs is de jure using Bazaar, but is it using it de facto? I read somewhere (I think it was here on HN) that the Emacs developers were leaning toward Git, but RMS decided on Bazaar because that's the office GNU DVCS. The comment or article I read said that someone made a good Bazaar/Git bridge, and most of the active Emacs developers are actually using Git, and bridging to Bazaar when they want to push to or pull from the official repository.
  - avar 16y ago
    That's true to a large extent as far as I can tell. I've seen reports on emacs-devel of commits taking a couple of minutes, and of having merge issues you'd never encounter in Git. Bazaar wasn't chosen for Emacs for technical reasons, and they appear to be suffering the consequences of that.

tzs 16y ago

GPL covers code. If you take code from Git to write an alternative implementation, yours has to be GPL. However, if all you do is take the file formats and the over-the-wire protocol, and write original code, it can be under whatever license you want. That seems to be what most of the alternative Git implementations have done. The Git repository format is remarkably simple. I'm confident that if for some reason all copies of Git disappeared (binaries and source) and I needed to keep working with my existing Git repositories, I could cobble together something that would get me basic DVCS functionality in a couple of weeks. By basic functionality, I mean the ability to check out revisions, view history, make changes to the working copy, and commit them, and to tag and branch and merge. (Heck, it was only a couple of weeks or so for Linus to write the thing once he decided to go for it, and he didn't have the benefit of having a well-designed and documented repository format and wire protocol handed to him). Any decent programmer could do the same or better. Thus, I don't think Git being GPL is any significant barrier to adoption by people who need a good DVCS in a closed source project.

gecko 16y ago
While I am keenly aware that the GPL only covers code, some major contributors to the Mercurial team have indicated that they do not believe it would be possible to make a compatible implementation without consulting Mercurial's source code. Whether you agree or not is immaterial at that point; why bother doing so when it will at best alienate the community, and at worst end in a messy lawsuit?
- tzs 16y ago
  I'd be curious why they think consulting the Mercurial source code would make the compatible implementation have to be GPL. Of course, rather than just go ahead and look and then write a compatible implementation from that knowledge, if I needed such a thing in a proprietary product, I'd pay a third party to read the Mercurial source and publish a specification of the file format, protocols, and rules for manipulating the repository (e.g., rules for locking things, and such). Then I'd implement from that specification. That should avoid any confrontation. There seem to be quite a few open source or free software projects where the developers think the license has more power than it really does. The reality is that all open source or free software licenses, even the more restrictive ones like GPL, will in fact let people do some things with one's software that one might not like. That's because these licenses are all based on relaxing the exclusive rights of the copyright holder. Unlike the typical proprietary software license, they aren't a mix of relaxing rights of the copyright holder and restricting rights of the user. Hence, if someone, including proprietary software companies, wishes to do something with with the code or the knowledge embedded therein, and what they want to do is something that doesn't require permission under copyright law, then they are free to do it. Personally, this is one of the reasons I have used the two clause BSD license for my recent works. People are going to find ways to legitimately do things I might not like. Instead of going with a restrictive free license like GPL and fantasizing that nothing bad can be done with my code and then being disappointed and pissed off when they do, better to just realize the price of giving users freedom is that they might do things I don't like, and not worry about it. Hence, BSD--the release and forget about it license. What I find kind of funny (hilarious, actually) is that the kind of protection that some developers wish to achieve IS actually available--via patents! The Mercurial developers can get what they want out of GPL by patenting their repository format and their protocols, and then making a free patent license available to implementations that use GPL.

tbrownaw 16y ago

> nor do I see people choosing Fossil and Monotone because they have distributed databases Monotone (and I believe Fossil) only version files/directories, and just happen to use SQLite as a local data store instead of rolling their own disk format. Veracity on the other hand, sounds like it allows simple databases as versioned objects in addition to directory trees. That's completely different and sounds very cool. I'm also not sure how necessary it is. For example monotone allows you to configure custom merger programs (intended for if you don't like KDiff3/Meld/etc) and to set a file attribute that prevents it from trying to use the internal line merger, so in theory you could just commit your database file (or disk image containing database files, or ...) and then write a custom merge program for them. But maybe what Veracity has will delta-compress better, and of course you'd get a merger that's already written.