Bazaar is really simple to use, though. If you know Git or Mercurial, you can learn it in 5 minutes, since the concepts map 1-to-1 and the commands are sensibly named.
He's not really actively involved, though. He's just been on a crusade lately to eradicate unwanted VCSs still used in older projects, including CVS for NetBSD and bzr for emacs. Honestly I'm glad he's doing it, I'm hoping it might make it more likely for newcomers to contribute to these projects. He has posted quite a few articles about these conversions on his blog [0], if you want to read about it.
Wonder if he's tried to evangelize on the OpenBSD mailing lists yet? The smackdown from Theo would be amusing.
To some extent, it's good he's doing this. To another, very few VCSs other than SCSS can really be called "obsolete", just primitive. Most of the time, people who go on about VCS migrations seem to be just bikeshedding and can't seem to give out specific justifications other than listing features that the upstream project likely doesn't need. It's not trivial either, changing a VCS often means changing the entire way a project is structured, for often uncertain gains.
Well, I can pick on OpenBSD's favorite: CVS repository corruption does happen, but CVS has no active integrity checking. You'll only detect it if you go far enough back... or run a conversion program. If you're lucky, you discover while it's covered by backups, but these issues can sleep for years. This caused a migration I was involved with to just become a scrape, as the code at the tip was fine.
(I'd also say that atomic commits are an excellent reason to leave CVS behind, but that can be argued.)
you should never use a vcs that has no ability to ask "is this repo in a valid state", or you may try to checkout the point version released to a large customer and be unable to do so. Data corruption can happen, even on raid drives (we're pretty sure it was a bug in the controller, but that doesn't change the effect.)
He has written a bunch of nontrivial code, and is running that code himself on his own machines (and those donated specifically for this purpose). He leaves it to the community to decide whether they want the products of that work. This seems the antithesis of bikeshedding.
esr knows how much of the open source community's success is driven from social factors as opposed to technical factors. I'm excited with his progress as well.
There were three distributed VCS that were in the running for a while. There was git, bazaar (bzr), and mercurial (hg). For a while people were using on all 3, but eventually git won out.
In my little experience with bzr, it was slow as molasses. The only competitive advantage it had against Git at the time was a simpler command line and better windows support (we are talking about the days when git commands were still spelled like git-branch, git-reflog and so on.)
Eventually Mercurial ate Bazaar's pie and now Git is slowly eroding projects away from Mercurial. All hail Linus, who managed to create two open source systems that became de-facto industry standards.
How does it compare speed-wise with git? That was the reason I switched from darcs 8 years ago. Some of my repos go back over a decade, and darcs had problems with them when there was just two years of history.
There was some issue with exponential running times in certain scenarios. I ran into an issue where two repositories were somehow in a state where a pull would never terminate. darcs definitely had problems.
No, ESR has never been involved with Emacs development. He has a history of invading prominent free software projects on the strength of his "hacker" cred, pissing all over them with his pet peeve of the day, insisting on making easy and unnecessary changes of shoddy quality, often at the expense of more important actual development that is underway, and then bragging about being Prominent FreeSoftware Developer to boost his dying hacker cred.
The only stand-alone software project ESR has truly driven himself is fetchmail. Fetchmail. Enough said.
Thank you for challenging these other fine gentlemen on this one point.
Just today I was just looking into why I wasn't getting automatic flyspell-mode activated on my Git commits. Now it seems I wont even need to research it further :)
But I got to thinking, early this morning, about the fact that I haven’t been able to settle on just one VCS. I use git for most things, but there’s a use case git doesn’t cover.
Kind of weird because you can totally wrap git for this use case as well (not like you need to commit all changes to your working set into one commit, and pretty easy to filter per-file changes).
A fun-seeming exercise anyways, I guess it doesn't matter what tool you're using underneath.
I thought his point was that these files don't have any relationship to each other, and that he would move them around on a regular basis. I can certainly see why one wouldn't want such files to share a git repo.
To be fair, if you want contributors, removing every needless roadblock they may encounter is certainly a worthwhile goal.
Using some archaic VCS which nobody has heard of, and which may or may not be available on your platform of choice, certainly doesn't help herd contributors to your project.
bzr is so strange. If its connection got stalled (third-world GSM or WiFi) its "stream" would hang. If a process has been killed due to a signal, garbage would remain. And if you run bzr check it will use about half GB of traffic, as if comparing the whole repo byte-by-byte.
Is it really that much less easy? Both require that you understand the nomenclature chosen by their respective systems ('objects'/'changesets', 'refs'/'repository').
And you could argue that it's better to use new terms rather than existing ones that carry possibly-incorrect assumptions, no? "Leaky abstractions" and all that.
I know what a repository is when I work with version control. I've been using version control for years and I never was confused about what the repository was.
The definition of 'object' is outside of the scope of the documentation for the 'push' command. Similarly with 'ref'.
From "man git":
"The object database contains objects of three main types: blobs, which hold file data;
trees, which point to blobs and other trees to build up directory hierarchies; and commits,
which each reference a single tree and some number of parent commits.
The commit, equivalent to what other systems call a "changeset" or "version", represents a
step in the project's history, and each parent represents an immediately preceding step.
Commits with more than one parent represent merges of independent lines of development.
All objects are named by the SHA-1 hash of their contents, normally written as a string of
40 hex digits. Such names are globally unique. The entire history leading up to a commit can
be vouched for by signing just that commit. A fourth object type, the tag, is provided for
this purpose.
When first created, objects are stored in individual files, but for efficiency may later be
compressed together into "pack files".
Named pointers called refs mark interesting points in history. A ref may contain the SHA-1
name of an object or the name of another ref. Refs with names beginning ref/head/ contain
the SHA-1 name of the most recent commit (or "head") of a branch under development. SHA-1
names of tags of interest are stored under ref/tags/. A special ref named HEAD contains the
name of the currently checked-out branch."
You know what I literally never had to do when learning SVN, bazaar, or mercurial? Learn a bunch of bullshit like "refs" or "objects" or "heads" or whatever the fuck.
It is genuinely insulting to assume me to have the time or the patience to read things like this. It's 2014. Interfaces need to be better and I refuse to use an interface that insults my time by attempting to make me learn a load of bullshit.
Usually, "refs" are things like branches or tags. A branch in git is just a text file that contains the hash of a commit (and that commit is the head of the branch). So it's a "reference" (or "ref") to that commit.
"Objects" are the things that are stored in the repository, like commits and file contents.
> Updates remote refs using local refs
So, if you had a branch called "dev", and your local version pointed to a different commit than the remote version, it will update the remote "dev" to match what you've got in your local one.
> while sending objects necessary to complete the given refs.
Of course, it's likely that the whole reason that your "dev" doesn't match the remote repository's "dev" is because you've changed some stuff - why else would you be pushing? - so you've got to also upload the new commit objects that the refs refer to, plus the file-content objects that the commits specify. In other words, 'complete the given refs'.
66 comments
[ 5.2 ms ] story [ 157 ms ] threadhttp://savannah.gnu.org/git/?group=emacs looks valid although I didn't try cloning.
bazaar is the provider for code hosting.
Maybe they do offer other options but aren't really proud of it, at least not enough to put it on the first page.
Anyway, I really think being bazaar-only it's a loss for launchpad. PPA's are great, but most people I know don't want learn bazaar just for it.
[0] http://esr.ibiblio.org/
To some extent, it's good he's doing this. To another, very few VCSs other than SCSS can really be called "obsolete", just primitive. Most of the time, people who go on about VCS migrations seem to be just bikeshedding and can't seem to give out specific justifications other than listing features that the upstream project likely doesn't need. It's not trivial either, changing a VCS often means changing the entire way a project is structured, for often uncertain gains.
(I'd also say that atomic commits are an excellent reason to leave CVS behind, but that can be argued.)
you should never use a vcs that has no ability to ask "is this repo in a valid state", or you may try to checkout the point version released to a large customer and be unable to do so. Data corruption can happen, even on raid drives (we're pretty sure it was a bug in the controller, but that doesn't change the effect.)
It's a smidge ironic that ESR himself is migrating a project away from it. :)
Eventually Mercurial ate Bazaar's pie and now Git is slowly eroding projects away from Mercurial. All hail Linus, who managed to create two open source systems that became de-facto industry standards.
With Linux it was the ability to use unix without having to stomp over to the university computer lab during the Finnish winter.
With git it was creating something that could handle merging patches from a disparate set of developers.
http://catb.org/~esr/reposurgeon/
http://www.catb.org/~esr/reposurgeon/features.html
The only stand-alone software project ESR has truly driven himself is fetchmail. Fetchmail. Enough said.
I doubt ESR is posting from Windows anyway.
Just today I was just looking into why I wasn't getting automatic flyspell-mode activated on my Git commits. Now it seems I wont even need to research it further :)
But I got to thinking, early this morning, about the fact that I haven’t been able to settle on just one VCS. I use git for most things, but there’s a use case git doesn’t cover.
http://esr.ibiblio.org/?p=6502
A fun-seeming exercise anyways, I guess it doesn't matter what tool you're using underneath.
Using some archaic VCS which nobody has heard of, and which may or may not be available on your platform of choice, certainly doesn't help herd contributors to your project.
git is much saner.
> Push changesets from the local repository to the specified destination.
:s/changesets/objects :s/local refs/local repository :s/specified destination/remote refs
Is it really that much less easy? Both require that you understand the nomenclature chosen by their respective systems ('objects'/'changesets', 'refs'/'repository').
An object is totally unspecified.
I know what a repository is when I work with version control. I've been using version control for years and I never was confused about what the repository was.
What the fuck is a ``ref''?
Git's shit.
From "man git":
"The object database contains objects of three main types: blobs, which hold file data; trees, which point to blobs and other trees to build up directory hierarchies; and commits, which each reference a single tree and some number of parent commits.
It is genuinely insulting to assume me to have the time or the patience to read things like this. It's 2014. Interfaces need to be better and I refuse to use an interface that insults my time by attempting to make me learn a load of bullshit.
Interesting priorities.
"Objects" are the things that are stored in the repository, like commits and file contents.
> Updates remote refs using local refs
So, if you had a branch called "dev", and your local version pointed to a different commit than the remote version, it will update the remote "dev" to match what you've got in your local one.
> while sending objects necessary to complete the given refs.
Of course, it's likely that the whole reason that your "dev" doesn't match the remote repository's "dev" is because you've changed some stuff - why else would you be pushing? - so you've got to also upload the new commit objects that the refs refer to, plus the file-content objects that the commits specify. In other words, 'complete the given refs'.
https://lists.gnu.org/archive/html/emacs-devel/2014-11/msg00...