3 ms·

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 an

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.

syntheticnature 12y ago
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.)
- x0x0 12y ago
  been there, done that, shit seriously sucked 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.)
jessaustin 12y ago
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.
rdc12 12y ago
Not waiting for your current VCS to bitrot is probably a good idea (assuming bzr dying isn't massive hyperbole)
- bronson 12y ago
  It's not hyperbole, development has pretty much ground to a halt: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes

syntheticnature 12y ago

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

x0x0 12y ago
been there, done that, shit seriously sucked 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.)

jessaustin 12y ago

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.

rdc12 12y ago

Not waiting for your current VCS to bitrot is probably a good idea (assuming bzr dying isn't massive hyperbole)

bronson 12y ago
It's not hyperbole, development has pretty much ground to a halt: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes