Frankly, PJ has gotten a bit religious herself lately. I still respect Groklaw as a source of fact -- but have been needing to pick that fact out from the editorial on increasingly frequent occasion.
Simple: support for views, and licensing that allows redistribution.
I absolutely, positively require view support, which nobody but BIND that I know of supports. TinyDNS might, but I can't so much as consider it due to the license; we're distributing servers with a fairly custom software environment, and DJB's terms make that a no-no. (This is also why we're using runit rather than daemontools).
Support views in something that supports pulling info (not just zone info, but definition of what the zones are, what the views are, what the ACLs are, etc a la named.conf) directly from a database and I'll be happy as a clam. 'Till then, I run BIND.
the "kernel developers use an unfree VC system" argument shows up only on the frontpage of the gnu.org Arch site, and not on the frontpage of either of the others.
Just because one of the selling points of Arch (on a GNU site) is that BK is unfree doesn't mean that this is the extent of its usefulness. Go read up on the wiki or elsewhere.
You might note, by the way, that the gnu.org Arch site is not the primary Arch site (certainly not the most frequently updated), though that's the one linked by the article. (www/wiki).gnuarch.org are Arch's primary frontends to the world.
Lastly they never even charged him with stealing a device. They charged him with interfering with the devices, and if that would have gone to court he would have most definately been found guilty because he documented the whole process.
Are you sure?
That is to say: Do you know the legal definition of the law regarding interfering with the devices? I wouldn't find it suprising *at all* if the only activities which could legally be considered interference were those which prevented the device from operating correctly. If he kept the device operating while unearthing and observing it, he might have some reasonable defense.
But that's speculation -- I don't know the law, and neither do you. If you want to assert that he "definately[sp] would have been found guilty", be sure you know the letter.
Java, or any of the other myriad of safe languages out there right now -- they're not exactly rare.
I think it's a little unkind to refer to C as archaic -- it still most assuredly has a place; that place just isn't doing application-level development. Someone has to maintain your JVM, for example, and Java quite certainly isn't the language to do it in.
Is anyone else concerned about the apparent contention over BitKeeper mentioned in the article?
Yup. But then, that's a (heated) discussion which has already taken place / is already taking place in plenty of other forums. No need to bring it in here too.
Well, legally, folks with piercings aren't a protected class. Off the top of my head (and it's been a while), race, ethnicity, gender, religion, maybe country of origin, and a few more are, but that's about it. Folks can discriminate against you all they want, as long as they aren't doing so because you're in a protected class.
What forces the free riders to assume the cost burden of open source development?
Self-interest, of course. If I use an open source product and want to fix a bug or add a feature, I either report the bug or feature request to the developer (providing, in effect, free QA resources) or do it myself (providing free development resources).
The rest (distributed repository, atomic operations, etc) are not nearly as important. Like I said in 12 years of using CVS I've never had an instance of a problem generated by non-atomic operations, and we do use CVS quite strenuously.
One thing I really can't stress enough: Distributed repository support is important. Really important. Night-and-day. The reason is that it enables new and completely different workflows, such that instead of conforming your workflow to the tool you can bend the tool to fit your workflow. If you're just one lone developer, maybe it doesn't matter -- but if you're working with others, it really is a huge thing in practice. Grokking GNU Arch, a presentation by Colin Walters (of Red Hat), includes a presentation covering, as well as the rationale behind the design decisions behind Arch, a comparison between typical CVS patch flow and (one example of) Arch patch flow. If you're still thinking in terms of traditional revision control then granted, the advantages of distributed support may not be obvious -- but if you're doing Free Software or commercial work with complex requirements, it's an exceedingly invaluable tool.
But distributed support isn't as powerful without changeset orientation. It makes more sense to say "give me Tom's tree, plus the SSL bugfixes from Aaron's development branch, plus my local changes from this working directory over here" (which Arch makes quite simple) than to say "give me Tom's tree, plus the changes in 1.1.2.3 from Aaron't ssl.c, 1.1.2.14 from Aaron't ssl.h"... and so forth.
An you mention, there's a huge leap in productivity going between no revision control and CVS. Part of what I'm trying to communicate is that there's another one coming up, and distributed revision control (with all the other features that make it work well -- changeset orientation, history-sensitive merging, and so forth) is right there.
At the moment I'm not looking at changing my SCM not so much because I'm totally satisfied with CVS but because I don't know which one to pick. On paper they are all better, but is it true in practice? With the switch to a different SCM goes the loss of the changelog. I don't want to change again in a year's time if the new tool is worse or not satisfactory or poorly supported. At any rate my own FLOSS project is on sourceforge, so I'll have to continue using CVS anyway, and for the work projects, they involve a lot of users, and I can't make that decision lightheartedly and toss away years of experience with CVS.
I'm glad to say that most of these objections don't apply. CSCVS (presently maintained by Robert Collins and myself... mostly Robert these days, since I'm flooded with work) lets you import your CVS history into Arch (and tries hard to intuit the parts of your history that CVS doesn't track -- though some of it, such as merge points, are simply lost forever). Hence, you need not lose your history. Because Arch has dumb server support, you can host your repository on any webspace you have sftp access to -- like that provided by SourceForge or Savannah. In a commercial environment the retraining aspect is the big one, though. I've convinced my lead architect at work that the switch is worthwhile (he's exceedingly anxious to force commits to pass our automated testing before they're committed to the company repository, which arch-pqm can enforce); it's a matter of time and training to actually make the switch, though, especially for the (thankfully few) Windows users.
Something posted as yourself on a ComputerWorld-hosted forum might be a bit better received.
How so?
Better reason to believe her claimed identity. It's not her initial post that I was arguing might be better received on ComputerWorld's site, but rather her post affirming her identity.
cweditor's grammar seems fine to me
Check again. She's missing punctuation, her style was a touch wordy, and there was at least one additional error that I found on first readthrough but can't relocate. Nothing bad at all by conversational standards, but I don't think it innately unreasonable to expect a professional editor to pay attention to such things even when off-duty.
All that said, she's validated her identity out-of-band, so my concern was in fact misplaced.
Your grammar seems a bit questionable for a professional editor. Something posted as yourself on a ComputerWorld-hosted forum might be a bit better received.
My beef isn't with BitMover, but rather with Linus choosing to use a tool with a license that either impells folks who work with him to buy a paid license or restrict what other projects they work on. One can argue that it's rather antisocial.
Well, actually, I did have a beef with BitMover, but I've since been in communication with LMV who'se indicated that there may well be quite a bit more to the story than I (and the other engineers on-staff at the time) was aware of.
No, it doesn't. It prevents people only from using the free version of BitKeeper to create competing systems. How evil!
No, not "to create competing systems". It stops folks who create competing systems from using the free version of BitKeeper for anything at all, including work not related to their creation of competing systems. That's a pretty damn critical distinction.
Oh, well, he's not nice. That changes everything!
*shrug*. Changing terms of a zero-cost license to stop an impoverished startup from being able to use it (after you're fully aware that they've become dependent on the tool and the terms) is indeed pretty damn unnice, and that's what I understood to have happened at the time I wrote the initial post. It's that kind of "unnice" that I'd argue is sufficient to make one wish to avoid having an individual or company as a supplier or other business partner.
I since receieved a private email from LMV describing his side of the incident, which does indeed sound plausible. Hence, I'm inclined to back off a bit on the position I took here, at least until I've gotten in touch with some people close to my former management and heard something one way or another.
Consider any claims re the BK license being "evil" or morally repugnant dropped. I still don't qualify for it, and will readily argue that Arch is an appropriate tool for the job, but I'll grant that BK is a vastly better tool than CVS.
Also (according to what I've read), arch doesn't support in-repository file and directory copying with history support.
Correct -- moves and renames are supported (of course), copying isn't. There's a very good reason for this: If you merge from a pre-copy branch where a change to the original was made to a post-copy branch with two (modified) files based off the original -- where does your first change apply? Is it really the Right Thing to apply it to both? Even worse, presume you're merging from a post-copy branch back to a pre-copy branch. Now you're really stuck -- do you try to apply the changes that were made to both copies to the original? How do you decide which one?
It's a situation that introduces cases where there is no intuitively right behaviour, and thus bad news. Now, there's been discussion of coming up with a standard tag to insert in a patchlog entry saying "this file is a copy of $FOO and inherits its history, but is in and of itself a distinct file; changes to it should not be propagated back to the original" which would be understood by the web-based and graphical history browsers. It's not implemented right now, because frankly nobody much cares about that feature. Perhaps at some point someone will care, and thus it'll get implemented (in the Arch history browsers; little-to-no change would be required in Arch itself).
All that said, there hasn't been a detailed feature comparison done between Arch and BK that I recall -- most of the people who would be interested in doing so don't qualify for the free BK license and aren't particularly interested in a paid one. Arguably, BK may have more features right now. (Arguably, Arch may have a better underlying design -- but then, that really depends on whether you ask Tom or Larry). Whether BK is sufficiently superior as to be worth giving up ones' ability to look at / play with / improve / bugfix / branch the source... well, after all the claims that I'm abandoning, that I think is where we differ.
I'll agree that good version control is about more than counting check boxes. That said, the features I'm mentioning are ones that are genuinely valid. Distributed repository support makes it dramatically easier for arbitrary third parties to branch the code (either to maintain revision-controlled private branches with changes local to their installation, to do work on new features for upstream inclusion, or for whatever other purpose) and also makes it easier for maintainers to control the process of reviewing and merging in those 3rd-party patches (hence BK making Linus's job easier). Further, a good distributed revision control system does all this without the security implications of giving Joe Yahoo commit access to your CVS server. History-sensitive merge support means you can maintain multiple branches, apply some of the same patches to both, and merge them together without generating loads of spurious conflicts (sufficiently advanced CVS users will know how much of a headache this is). Dumb server support means that I can open access to my revision control repository to the world (or my intranet) without anything more than a patch of webspace available -- no more depending on a CVS host such as SourceForge. Changeset-level granularity eliminates issues where a developer makes two dependent changes and then someone else checks out only one of those changes (doing a partial-tree update or somesuch) and thinks the tree's broken; permits sets of dependent changes to be cherry-picked between branches (so that I can take Feature A -- which may involve changing 3 files -- from Branch Foo and merge it into Branch Bar -- in one atomic step), makes for better automatic changelog generation, and is otherwise damn useful in practice. And then there's stuff like supporting moves and renames (and correctly merging between a branch where a more or rename has happened and another where it hasn't) -- things folks would expect any decent SCM to do that CVS just doesn't.
What I'm saying here is that the features I'm mentioning are the things that I make use of in real-world practice to the point where I'd be hurting to be without them again. I'm not listing the piddly bits like automatic changelog generation, but rather real-world functionality that makes my life easier as a Free Software developer. (If I were talking about my other life as a commercial software developer, I'd be talking about arch-pqm validating that the test suite passes before permitting a checkin to go through to the main repository, or how Arch makes it easy to use different branches for organizational purposes like tracking down to the individual changeset what code the QA department has reviewed and approved).
Re SourceForge not switching, I've actually talked with them about it before: No matter how theoretically scalable an alternate SCM is, they're not going to switch until someone on the same scale of operations as themselves is already using it succesfully. And on the topic of usability: Arch and BK are certainly not as easy to learn as CVS. SVN, I'll argue, is OTOH every bit as easy as CVS to use -- just much harder to administer. (IMNSHO, the post-learning-curve benefits of distributed version control are more than sufficient to justify the up-front cost; however, if your goals are different, SVN is not necessarily a bad choice).
Yes, CVS may "get the job done" -- but then, your definition of "the job" has been shaped by your use of that tool and others like it. Modern revision control systems do a much bigger job, and do it much better -- in a way that makes life easier not only for the core development team, but also for 3rd parties who want to contribute or maintain their own trees.
One of the complaints I've heard from ex-SVN users that they've on occasion needed to rebuild their datastore. One of the issues I've seen with CVS users running CSCVS is corruptions occuring in the,v files (presumably while they're rewritten to add new data) preventing access to old history (often *very* old history; since these parts further down the file don't get accessed much, it's rare that their corruption is detected until something like cscvs is used). One of the nice things about being an Arch user is being able to take advantage of the nature of its write-once datastore format for backup, integrity-checking, enhancing OS-level security, and like purposes.
Sure, the backend doesn't matter if the abstractions don't leak and you don't want to take advantage of any of the side-effects that one (particularly nice) storage format may have over another. When one gets sufficiently far into the "advanced user" category, though, or encounters bugginess inside the code that's hidden behind the abstractions -- well, then, whatever's sitting behind the curtain starts to make a difference.
Slashdot Mirror
Frankly, PJ has gotten a bit religious herself lately. I still respect Groklaw as a source of fact -- but have been needing to pick that fact out from the editorial on increasingly frequent occasion.
Simple: support for views, and licensing that allows redistribution.
I absolutely, positively require view support, which nobody but BIND that I know of supports. TinyDNS might, but I can't so much as consider it due to the license; we're distributing servers with a fairly custom software environment, and DJB's terms make that a no-no. (This is also why we're using runit rather than daemontools).
Support views in something that supports pulling info (not just zone info, but definition of what the zones are, what the views are, what the ACLs are, etc a la named.conf) directly from a database and I'll be happy as a clam. 'Till then, I run BIND.
the "kernel developers use an unfree VC system" argument shows up only on the frontpage of the gnu.org Arch site, and not on the frontpage of either of the others.
Just because one of the selling points of Arch (on a GNU site) is that BK is unfree doesn't mean that this is the extent of its usefulness. Go read up on the wiki or elsewhere.
You might note, by the way, that the gnu.org Arch site is not the primary Arch site (certainly not the most frequently updated), though that's the one linked by the article. (www/wiki).gnuarch.org are Arch's primary frontends to the world.
Lastly they never even charged him with stealing a device. They charged him with interfering with the devices, and if that would have gone to court he would have most definately been found guilty because he documented the whole process.
Are you sure?
That is to say: Do you know the legal definition of the law regarding interfering with the devices? I wouldn't find it suprising *at all* if the only activities which could legally be considered interference were those which prevented the device from operating correctly. If he kept the device operating while unearthing and observing it, he might have some reasonable defense.
But that's speculation -- I don't know the law, and neither do you. If you want to assert that he "definately[sp] would have been found guilty", be sure you know the letter.
That's just the HURD people being idiotic.
Folks with better design sense have implemented their own microkernels with vastly better performance and in far, far less time.
Microkernels are not necessarily slower than dirt -- just poorly implemented ones (the HURD being a prime example).
See VSTa for a counterexample.
JikesRVM is written in Java.
Yes, but it's a research VM. That's a horse of an entirely different color.
Java, or any of the other myriad of safe languages out there right now -- they're not exactly rare.
I think it's a little unkind to refer to C as archaic -- it still most assuredly has a place; that place just isn't doing application-level development. Someone has to maintain your JVM, for example, and Java quite certainly isn't the language to do it in.
AFAIK is the only language that automatically does bounds checking
Not by a long shot.
Python, most Scheme implementations, Haskel, ADA, and many, many languages provide similar safety features.
As you say, though, pity they're not more often used.
Is anyone else concerned about the apparent contention over BitKeeper mentioned in the article?
Yup. But then, that's a (heated) discussion which has already taken place / is already taking place in plenty of other forums. No need to bring it in here too.
(As an aside, I use Arch).
Pbblblbblbl!!!
Well, legally, folks with piercings aren't a protected class. Off the top of my head (and it's been a while), race, ethnicity, gender, religion, maybe country of origin, and a few more are, but that's about it. Folks can discriminate against you all they want, as long as they aren't doing so because you're in a protected class.
Don't ask me why, that's how the law works.
Well, legally, folks with piercings aren't a protected class. Minorities and members of religious groups are.
Don't ask me why, that's how the law works.
What forces the free riders to assume the cost burden of open source development?
Self-interest, of course. If I use an open source product and want to fix a bug or add a feature, I either report the bug or feature request to the developer (providing, in effect, free QA resources) or do it myself (providing free development resources).
The rest (distributed repository, atomic operations, etc) are not nearly as important. Like I said in 12 years of using CVS I've never had an instance of a problem generated by non-atomic operations, and we do use CVS quite strenuously.
One thing I really can't stress enough: Distributed repository support is important. Really important. Night-and-day. The reason is that it enables new and completely different workflows, such that instead of conforming your workflow to the tool you can bend the tool to fit your workflow. If you're just one lone developer, maybe it doesn't matter -- but if you're working with others, it really is a huge thing in practice. Grokking GNU Arch, a presentation by Colin Walters (of Red Hat), includes a presentation covering, as well as the rationale behind the design decisions behind Arch, a comparison between typical CVS patch flow and (one example of) Arch patch flow. If you're still thinking in terms of traditional revision control then granted, the advantages of distributed support may not be obvious -- but if you're doing Free Software or commercial work with complex requirements, it's an exceedingly invaluable tool.
But distributed support isn't as powerful without changeset orientation. It makes more sense to say "give me Tom's tree, plus the SSL bugfixes from Aaron's development branch, plus my local changes from this working directory over here" (which Arch makes quite simple) than to say "give me Tom's tree, plus the changes in 1.1.2.3 from Aaron't ssl.c, 1.1.2.14 from Aaron't ssl.h"... and so forth.
An you mention, there's a huge leap in productivity going between no revision control and CVS. Part of what I'm trying to communicate is that there's another one coming up, and distributed revision control (with all the other features that make it work well -- changeset orientation, history-sensitive merging, and so forth) is right there.
At the moment I'm not looking at changing my SCM not so much because I'm totally satisfied with CVS but because I don't know which one to pick. On paper they are all better, but is it true in practice? With the switch to a different SCM goes the loss of the changelog. I don't want to change again in a year's time if the new tool is worse or not satisfactory or poorly supported. At any rate my own FLOSS project is on sourceforge, so I'll have to continue using CVS anyway, and for the work projects, they involve a lot of users, and I can't make that decision lightheartedly and toss away years of experience with CVS.
I'm glad to say that most of these objections don't apply. CSCVS (presently maintained by Robert Collins and myself... mostly Robert these days, since I'm flooded with work) lets you import your CVS history into Arch (and tries hard to intuit the parts of your history that CVS doesn't track -- though some of it, such as merge points, are simply lost forever). Hence, you need not lose your history. Because Arch has dumb server support, you can host your repository on any webspace you have sftp access to -- like that provided by SourceForge or Savannah. In a commercial environment the retraining aspect is the big one, though. I've convinced my lead architect at work that the switch is worthwhile (he's exceedingly anxious to force commits to pass our automated testing before they're committed to the company repository, which arch-pqm can enforce); it's a matter of time and training to actually make the switch, though, especially for the (thankfully few) Windows users.
"Atrocious" varies by context -- and in the context of your post above, her spelling and grammar is indeed quite good.
All that said -- yes, she's validated that she really is who she said she was, so the whole thing's a non-issue.
All that said, she's validated her identity out-of-band, so my concern was in fact misplaced.
Your grammar seems a bit questionable for a professional editor. Something posted as yourself on a ComputerWorld-hosted forum might be a bit better received.
My beef isn't with BitMover, but rather with Linus choosing to use a tool with a license that either impells folks who work with him to buy a paid license or restrict what other projects they work on. One can argue that it's rather antisocial.
Well, actually, I did have a beef with BitMover, but I've since been in communication with LMV who'se indicated that there may well be quite a bit more to the story than I (and the other engineers on-staff at the time) was aware of.
No, it doesn't. It prevents people only from using the free version of BitKeeper to create competing systems. How evil!
No, not "to create competing systems". It stops folks who create competing systems from using the free version of BitKeeper for anything at all, including work not related to their creation of competing systems. That's a pretty damn critical distinction.
Oh, well, he's not nice. That changes everything!
*shrug*. Changing terms of a zero-cost license to stop an impoverished startup from being able to use it (after you're fully aware that they've become dependent on the tool and the terms) is indeed pretty damn unnice, and that's what I understood to have happened at the time I wrote the initial post. It's that kind of "unnice" that I'd argue is sufficient to make one wish to avoid having an individual or company as a supplier or other business partner.
I since receieved a private email from LMV describing his side of the incident, which does indeed sound plausible. Hence, I'm inclined to back off a bit on the position I took here, at least until I've gotten in touch with some people close to my former management and heard something one way or another.
Consider any claims re the BK license being "evil" or morally repugnant dropped. I still don't qualify for it, and will readily argue that Arch is an appropriate tool for the job, but I'll grant that BK is a vastly better tool than CVS.
Also (according to what I've read), arch doesn't support in-repository file and directory copying with history support.
Correct -- moves and renames are supported (of course), copying isn't. There's a very good reason for this: If you merge from a pre-copy branch where a change to the original was made to a post-copy branch with two (modified) files based off the original -- where does your first change apply? Is it really the Right Thing to apply it to both? Even worse, presume you're merging from a post-copy branch back to a pre-copy branch. Now you're really stuck -- do you try to apply the changes that were made to both copies to the original? How do you decide which one?
It's a situation that introduces cases where there is no intuitively right behaviour, and thus bad news. Now, there's been discussion of coming up with a standard tag to insert in a patchlog entry saying "this file is a copy of $FOO and inherits its history, but is in and of itself a distinct file; changes to it should not be propagated back to the original" which would be understood by the web-based and graphical history browsers. It's not implemented right now, because frankly nobody much cares about that feature. Perhaps at some point someone will care, and thus it'll get implemented (in the Arch history browsers; little-to-no change would be required in Arch itself).
All that said, there hasn't been a detailed feature comparison done between Arch and BK that I recall -- most of the people who would be interested in doing so don't qualify for the free BK license and aren't particularly interested in a paid one. Arguably, BK may have more features right now. (Arguably, Arch may have a better underlying design -- but then, that really depends on whether you ask Tom or Larry). Whether BK is sufficiently superior as to be worth giving up ones' ability to look at / play with / improve / bugfix / branch the source... well, after all the claims that I'm abandoning, that I think is where we differ.
I'll agree that good version control is about more than counting check boxes. That said, the features I'm mentioning are ones that are genuinely valid. Distributed repository support makes it dramatically easier for arbitrary third parties to branch the code (either to maintain revision-controlled private branches with changes local to their installation, to do work on new features for upstream inclusion, or for whatever other purpose) and also makes it easier for maintainers to control the process of reviewing and merging in those 3rd-party patches (hence BK making Linus's job easier). Further, a good distributed revision control system does all this without the security implications of giving Joe Yahoo commit access to your CVS server. History-sensitive merge support means you can maintain multiple branches, apply some of the same patches to both, and merge them together without generating loads of spurious conflicts (sufficiently advanced CVS users will know how much of a headache this is). Dumb server support means that I can open access to my revision control repository to the world (or my intranet) without anything more than a patch of webspace available -- no more depending on a CVS host such as SourceForge. Changeset-level granularity eliminates issues where a developer makes two dependent changes and then someone else checks out only one of those changes (doing a partial-tree update or somesuch) and thinks the tree's broken; permits sets of dependent changes to be cherry-picked between branches (so that I can take Feature A -- which may involve changing 3 files -- from Branch Foo and merge it into Branch Bar -- in one atomic step), makes for better automatic changelog generation, and is otherwise damn useful in practice. And then there's stuff like supporting moves and renames (and correctly merging between a branch where a more or rename has happened and another where it hasn't) -- things folks would expect any decent SCM to do that CVS just doesn't.
What I'm saying here is that the features I'm mentioning are the things that I make use of in real-world practice to the point where I'd be hurting to be without them again. I'm not listing the piddly bits like automatic changelog generation, but rather real-world functionality that makes my life easier as a Free Software developer. (If I were talking about my other life as a commercial software developer, I'd be talking about arch-pqm validating that the test suite passes before permitting a checkin to go through to the main repository, or how Arch makes it easy to use different branches for organizational purposes like tracking down to the individual changeset what code the QA department has reviewed and approved).
Re SourceForge not switching, I've actually talked with them about it before: No matter how theoretically scalable an alternate SCM is, they're not going to switch until someone on the same scale of operations as themselves is already using it succesfully. And on the topic of usability: Arch and BK are certainly not as easy to learn as CVS. SVN, I'll argue, is OTOH every bit as easy as CVS to use -- just much harder to administer. (IMNSHO, the post-learning-curve benefits of distributed version control are more than sufficient to justify the up-front cost; however, if your goals are different, SVN is not necessarily a bad choice).
Yes, CVS may "get the job done" -- but then, your definition of "the job" has been shaped by your use of that tool and others like it. Modern revision control systems do a much bigger job, and do it much better -- in a way that makes life easier not only for the core development team, but also for 3rd parties who want to contribute or maintain their own trees.
Yes, yes, I know that there's a BK->CVS mirror. Still means that one has to use suboptimal means to submit changesets back upstream.
That said -- frankly, I regret my involvement in this thread; I was, admittedly, shooting my mouth off without cause.
One of the complaints I've heard from ex-SVN users that they've on occasion needed to rebuild their datastore. One of the issues I've seen with CVS users running CSCVS is corruptions occuring in the ,v files (presumably while they're rewritten to add new data) preventing access to old history (often *very* old history; since these parts further down the file don't get accessed much, it's rare that their corruption is detected until something like cscvs is used). One of the nice things about being an Arch user is being able to take advantage of the nature of its write-once datastore format for backup, integrity-checking, enhancing OS-level security, and like purposes.
Sure, the backend doesn't matter if the abstractions don't leak and you don't want to take advantage of any of the side-effects that one (particularly nice) storage format may have over another. When one gets sufficiently far into the "advanced user" category, though, or encounters bugginess inside the code that's hidden behind the abstractions -- well, then, whatever's sitting behind the curtain starts to make a difference.