Slashdot Mirror

Larry McVoy says in the interview that one problem with reverse-engineering BK is "Corruption. BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it."

This would make me feel so good about using BK for my commercial project. Apparently, if anyone corrupts their own personal changeset store, the whole system is screwed.

I am considering various cm's for a project.

Arch and Monotone have been mentioned. I also came across OpenCM, which seems to have merit too.

Is it that openCM is little-known, or because of some impediment in the software? Or lack of track record for a newly developped cm?

There are lots of such tools, including CVS, Subversion (SVN), GNU arch, Monotone, Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Superversion, Codeville, Bazaar, Arx, and Bazaar-NG.

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

It is now official. Netcraft confirms: Eros is dying

One more crippling bombshell hit the already beleaguered Eros community when IDC confirmed that Eros market share has dropped yet again, now down to less than a fraction of 0.0001 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Eros has lost more market share, this news serves to reinforce what we've known all along. Eros is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Research Projects That Promise Much But Go Nowhere networking test.

You don't need to be a Kreskin to predict Eros's future. The hand writing is on the wall: Eros faces a bleak future. In fact there won't be any future at all for Eros because Eros is dying. Things are looking very bad for Eros. As many of us are already aware, Eros continues to lose market share. Red ink flows like a river of blood.

Let's keep to the facts and look at the numbers.

Eros leader Jonathan Shapiro states that there are 7 users of Eros. How many users of KeyKos are there? Let's see. KeyKos is at about 8 percent of the Eros market. Therefore there are 7 + 1 = 8 users of either Eros or KeyKos. This is consistent with the number of Eros Usenet posts.

Due to troubles at University of Pennsylvania, abysmal development speed and so on, Eros went through a "focus shift" by doing a useless rewrite in C and was taken over by Johns Hopkins University, who attempted to continue development on this troubled OS. Then the project was sidetracked while precious development resources went towards creating Yet Another Useless Version Control System. Now it is dead, its corpse turned over to yet another charnel house.

All major surveys show that Eros has steadily declined in market share. Eros is very sick and its long term survival prospects are very dim. If Eros is to survive at all it will be among OS dilettante dabblers. Eros continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Eros is dead.

Fact: Eros is dying

It is now official. Netcraft confirms: Eros is dying

One more crippling bombshell hit the already beleaguered Eros community when IDC confirmed that Eros market share has dropped yet again, now down to less than a fraction of 0.0001 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Eros has lost more market share, this news serves to reinforce what we've known all along. Eros is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Research Projects That Promise Much But Go Nowhere networking test.

You don't need to be a Kreskin to predict Eros's future. The hand writing is on the wall: Eros faces a bleak future. In fact there won't be any future at all for Eros because Eros is dying. Things are looking very bad for Eros. As many of us are already aware, Eros continues to lose market share. Red ink flows like a river of blood.

Let's keep to the facts and look at the numbers.

Eros leader Jonathan Shapiro states that there are 7 users of Eros. How many users of KeyKos are there? Let's see. KeyKos is at about 8 percent of the Eros market. Therefore there are 7 + 1 = 8 users of either Eros or KeyKos. This is consistent with the number of Eros Usenet posts.

Due to troubles at University of Pennsylvania, abysmal development speed and so on, Eros went through a "focus shift" by doing a useless rewrite in C and was taken over by Johns Hopkins University, who attempted to continue development on this troubled OS. Then the project was sidetracked while precious development resources went towards creating Yet Another Useless Version Control System. Now it is dead, its corpse turned over to yet another charnel house.

All major surveys show that Eros has steadily declined in market share. Eros is very sick and its long term survival prospects are very dim. If Eros is to survive at all it will be among OS dilettante dabblers. Eros continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Eros is dead.

Fact: Eros is dying

It is now official. Netcraft confirms: Eros is dying

One more crippling bombshell hit the already beleaguered Eros community when IDC confirmed that Eros market share has dropped yet again, now down to less than a fraction of 0.0001 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Eros has lost more market share, this news serves to reinforce what we've known all along. Eros is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Research Projects That Promise Much But Go Nowhere networking test.

You don't need to be a Kreskin to predict Eros's future. The hand writing is on the wall: Eros faces a bleak future. In fact there won't be any future at all for Eros because Eros is dying. Things are looking very bad for Eros. As many of us are already aware, Eros continues to lose market share. Red ink flows like a river of blood.

Let's keep to the facts and look at the numbers.

Eros leader Jonathan Shapiro states that there are 7 users of Eros. How many users of KeyKos are there? Let's see. KeyKos is at about 8 percent of the Eros market. Therefore there are 7 + 1 = 8 users of either Eros or KeyKos. This is consistent with the number of Eros Usenet posts.

Due to troubles at University of Pennsylvania, abysmal development speed and so on, Eros went through a "focus shift" by doing a useless rewrite in C and was taken over by Johns Hopkins University, who attempted to continue development on this troubled OS. Then the project was sidetracked while precious development resources went towards creating Yet Another Useless Version Control System. Now it is dead, its corpse turned over to yet another charnel house.

All major surveys show that Eros has steadily declined in market share. Eros is very sick and its long term survival prospects are very dim. If Eros is to survive at all it will be among OS dilettante dabblers. Eros continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Eros is dead.

Fact: Eros is dying

It is now official. Netcraft confirms: Eros is dying

One more crippling bombshell hit the already beleaguered Eros community when IDC confirmed that Eros market share has dropped yet again, now down to less than a fraction of 0.0001 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Eros has lost more market share, this news serves to reinforce what we've known all along. Eros is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Research Projects That Promise Much But Go Nowhere networking test.

You don't need to be a Kreskin to predict Eros's future. The hand writing is on the wall: Eros faces a bleak future. In fact there won't be any future at all for Eros because Eros is dying. Things are looking very bad for Eros. As many of us are already aware, Eros continues to lose market share. Red ink flows like a river of blood.

Let's keep to the facts and look at the numbers.

Eros leader Jonathan Shapiro states that there are 7 users of Eros. How many users of KeyKos are there? Let's see. KeyKos is at about 8 percent of the Eros market. Therefore there are 7 + 1 = 8 users of either Eros or KeyKos. This is consistent with the number of Eros Usenet posts.

Due to troubles at University of Pennsylvania, abysmal development speed and so on, Eros went through a "focus shift" by doing a useless rewrite in C and was taken over by Johns Hopkins University, who attempted to continue development on this troubled OS. Then the project was sidetracked while precious development resources went towards creating Yet Another Useless Version Control System. Now it is dead, its corpse turned over to yet another charnel house.

All major surveys show that Eros has steadily declined in market share. Eros is very sick and its long term survival prospects are very dim. If Eros is to survive at all it will be among OS dilettante dabblers. Eros continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Eros is dead.

Fact: Eros is dying

It is now official. Netcraft confirms: Eros is dying

One more crippling bombshell hit the already beleaguered Eros community when IDC confirmed that Eros market share has dropped yet again, now down to less than a fraction of 0.0001 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Eros has lost more market share, this news serves to reinforce what we've known all along. Eros is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Research Projects That Promise Much But Go Nowhere networking test.

You don't need to be a Kreskin to predict Eros's future. The hand writing is on the wall: Eros faces a bleak future. In fact there won't be any future at all for Eros because Eros is dying. Things are looking very bad for Eros. As many of us are already aware, Eros continues to lose market share. Red ink flows like a river of blood.

Let's keep to the facts and look at the numbers.

Eros leader Jonathan Shapiro states that there are 7 users of Eros. How many users of KeyKos are there? Let's see. KeyKos is at about 8 percent of the Eros market. Therefore there are 7 + 1 = 8 users of either Eros or KeyKos. This is consistent with the number of Eros Usenet posts.

Due to troubles at University of Pennsylvania, abysmal development speed and so on, Eros went through a "focus shift" by doing a useless rewrite in C and was taken over by Johns Hopkins University, who attempted to continue development on this troubled OS. Then the project was sidetracked while precious development resources went towards creating Yet Another Useless Version Control System. Now it is dead, its corpse turned over to yet another charnel house.

All major surveys show that Eros has steadily declined in market share. Eros is very sick and its long term survival prospects are very dim. If Eros is to survive at all it will be among OS dilettante dabblers. Eros continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Eros is dead.

Fact: Eros is dying

It is now official. Netcraft confirms: Eros is dying

One more crippling bombshell hit the already beleaguered Eros community when IDC confirmed that Eros market share has dropped yet again, now down to less than a fraction of 0.0001 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Eros has lost more market share, this news serves to reinforce what we've known all along. Eros is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Research Projects That Promise Much But Go Nowhere networking test.

You don't need to be a Kreskin to predict Eros's future. The hand writing is on the wall: Eros faces a bleak future. In fact there won't be any future at all for Eros because Eros is dying. Things are looking very bad for Eros. As many of us are already aware, Eros continues to lose market share. Red ink flows like a river of blood.

Let's keep to the facts and look at the numbers.

Eros leader Jonathan Shapiro states that there are 7 users of Eros. How many users of KeyKos are there? Let's see. KeyKos at about 8 percent of the Eros market. Therefore there are 7 + 1 = 8 users of either Eros or KeyKos. This is consistent with the number of Eros Usenet posts.

Due to troubles at University of Pennsylvania, abysmal development speed and so on, Eros went through a "focus shift" by doing a useless rewrite in C and was taken over by Johns Hopkins University, who attempted to continue development on this troubled OS. Then the project was sidetracked while precious development resources went towards creating Yet Another Useless Version Control System. Now it is dead, its corpse turned over to yet another charnel house.

All major surveys show that Eros has steadily declined in market share. Eros is very sick and its long term survival prospects are very dim. If Eros is to survive at all it will be among OS dilettante dabblers. Eros continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Eros is dead.

Fact: Eros is dying

Actually, you should check out OpenCM. (soon to make it's 1.0 release).

Also OpenCM, a particularly elegant open source tool by the creators of the (quite cool) EROS.

Tends to be overlooked, perhaps because:

The website says it's an early version. Yeah, as rated by the ultra-strict EROS people. But compared to arch or whatever, it's pretty far along.

it calls itself a "configuration management" system, which is corporate-drone-programmer speak for what most Free coders call "version control" systems, so searching for "version" doesn't tend to yield it.

1. The Boehm-Weiser (BW) collector is not as portable as we had hoped. There are a number of platforms we wanted to run on where it just doesn't run at all. Relatively small changes to the target runtime can create a need to port it all over again. OpenBSD, in particular, was an ongoing hassle until we abandoned BW. Hans, I hasten to add, was quite encouraging, but he simply doesn't have time to adequately support the collector.

2. The BW collector doesn't work in our application. OpenCM has a few very large objects. For reasons we don't really understand, this tends to cause a great deal of garbage retention when running the BW collector. Enough so that the OpenCM server crashed a lot when using it. Please note that this was NOT a bug involving falsely retained pointers, as later experience showed.

3. Conservative collectors are actually too conservative. If you are willing to make very modest changes in your source code as you design the app, there prove to be very natural places in the code for collection, and the resulting collector is quite efficient.

4. Independent of the collector, we also hacked together an exceptions package. This was also the right thing to do, but it's easy to trip over it in certain ways. The point of mentioning this is that once you do exceptions the pointer tracking becomes damned near hopeless and you essentially have to go to GC.

   I think the way to say this is: exceptions + GC reduces your error handling code by a lot. Instead of three lines of error check on every procedure call, the error checking is confined to logical recovery points in the program, and you don't have to mess around simulating multiple return values in order to return a result code in parallel with the actually intended return value.

5. To provide malloc pluggability, we implemented an explicit free operation. This lets us interoperate compatibly with other libraries and do leak detection. Turns out to be very handy in lots of ways.

6. Hybrid storage management works very well. For example, our diff routine explicitly frees some of its local storage (example) [Sorry -- this link will go stale within the next few weeks because the OpenCM web interface will change in a way that makes it obsolete. If the link doesn't work for you, try looking for the same file in .../DEV/opencm/...] This is actually quite wonderful, as it lets us build certain libraries to be GC compatible without being GC dependent. One of the challenges in using a GC'd runtime in a library is compatibility with an enclosing application that doesn't use GC. We haven't tried it yet, but it looks like our gcmalloc code will handle this.

Eventually, we gave up on the BW collector and wrote our own. Our collector is conceptually very similar to the collector that Keith Packard built for Nickle, though we've since built from there. A variant of the Nickle collector is also used as a debugging leak tracer for X11.

The OpenCM GC system is reasonably well standalone. We need to document it, but others might want to look at it when we cut our next release.

On the whole, I'ld say that GC for this app was definitely the right thing to do. Once you get into object caches it becomes very hard to locate all of the objects and decide when to free them. We were able to use a conservative approach with no real hassle, and heap size is fairly well bounded by the assisted GC approach we took.

On the other hand, I would not recommend a pure conservative collector for a pro

1. The Boehm-Weiser (BW) collector is not as portable as we had hoped. There are a number of platforms we wanted to run on where it just doesn't run at all. Relatively small changes to the target runtime can create a need to port it all over again. OpenBSD, in particular, was an ongoing hassle until we abandoned BW. Hans, I hasten to add, was quite encouraging, but he simply doesn't have time to adequately support the collector.

2. The BW collector doesn't work in our application. OpenCM has a few very large objects. For reasons we don't really understand, this tends to cause a great deal of garbage retention when running the BW collector. Enough so that the OpenCM server crashed a lot when using it. Please note that this was NOT a bug involving falsely retained pointers, as later experience showed.

3. Conservative collectors are actually too conservative. If you are willing to make very modest changes in your source code as you design the app, there prove to be very natural places in the code for collection, and the resulting collector is quite efficient.

4. Independent of the collector, we also hacked together an exceptions package. This was also the right thing to do, but it's easy to trip over it in certain ways. The point of mentioning this is that once you do exceptions the pointer tracking becomes damned near hopeless and you essentially have to go to GC.

   I think the way to say this is: exceptions + GC reduces your error handling code by a lot. Instead of three lines of error check on every procedure call, the error checking is confined to logical recovery points in the program, and you don't have to mess around simulating multiple return values in order to return a result code in parallel with the actually intended return value.

5. To provide malloc pluggability, we implemented an explicit free operation. This lets us interoperate compatibly with other libraries and do leak detection. Turns out to be very handy in lots of ways.

6. Hybrid storage management works very well. For example, our diff routine explicitly frees some of its local storage (example) [Sorry -- this link will go stale within the next few weeks because the OpenCM web interface will change in a way that makes it obsolete. If the link doesn't work for you, try looking for the same file in .../DEV/opencm/...] This is actually quite wonderful, as it lets us build certain libraries to be GC compatible without being GC dependent. One of the challenges in using a GC'd runtime in a library is compatibility with an enclosing application that doesn't use GC. We haven't tried it yet, but it looks like our gcmalloc code will handle this.

Eventually, we gave up on the BW collector and wrote our own. Our collector is conceptually very similar to the collector that Keith Packard built for Nickle, though we've since built from there. A variant of the Nickle collector is also used as a debugging leak tracer for X11.

The OpenCM GC system is reasonably well standalone. We need to document it, but others might want to look at it when we cut our next release.

On the whole, I'ld say that GC for this app was definitely the right thing to do. Once you get into object caches it becomes very hard to locate all of the objects and decide when to free them. We were able to use a conservative approach with no real hassle, and heap size is fairly well bounded by the assisted GC approach we took.

On the other hand, I would not recommend a pure conservative collector for a pro

OpenCM is another free alternative. It's pretty nice.

OpenCM looks to me to be much more useful and stable than subversion.

OpenCM

At least for content management systems, there is a very solid CVS replacement:

OpenCM.

One of the many features of OpenCM is cryptographic integrity protection.

Go, read their webpage.

If you want to see how tracking your config from CVS would look, the BSD folks have the entire source for their systems in CVS.

<SHAMELESS PLUG>
You might also try OpenCM for this.
</SHAMELESS PLUG>

Todd Fries of the OpenBSD project has been working on OpenCM quite a bit, and hopefully someday fairly soon (by which I mean a year if we're lucky), OpenBSD will be using OpenCM instead of CVS.

Well, the BSD license says that the license/attribution notice must stay with the code and its derivatives, but since you don't necessarily have a right to look at BSD-derived code, and there's nothing about using preprocessor directives to eliminate the comments from the binary, there's no way to know.

But the license says:

* 2. Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials
* provided with the distribution.

Roughly, at least. (I just copied this out of a header at work I'm supposed to be working on.) If it's a binary only distribution, and they don't include the copyright notices and a copy of the license, they're violating the license.

I'm sure it happens a lot, but it's just as illegal as selling GPLed software without giving out the source (or making copies of Windows XP).

he recalls seeing some files working at MS that were BSD-licensed code, and IIRC the license notice wasn't actually stripped out, but it had been taken out of context and slapped down at the bottom of the file, in a not-likely-to-be-read place.

Yeah, some of the headers included with Visual C++ have BSD copyrights on them as well (usually down at the end). They do the same when they're using a third-party library. IIRC much of their ANSI C/C++ library was done by P.J. Plauger (sp?), they moved all his (C)'s to the end of the file and put a (C) Microsoft up at the top.

It doesn't seem very polite, but OTOH it does comply with the license. Much preferable to removing the notices.

As others have hinted (but did not provide any details), an alternative to subversion and arch is "opencm":

http://www.opencm.org

Unfortunately, like subversion, opencm is still a work-in-progress, but it appears to have a lot of potential. Progress appears to be occurring at a steady, but moderate, pace.

Features:

• Doesn't require (part of?) apache to build, unlike subversion. (yay!)

• Developers have explicitly stated that repository replication and disconnected commits will be implemented in a future version. I think subverion might someday support these (and I wouldn't hold my breath), but the opencm developers seem to have put a much higher priority on these (i.e., explicit mention as "coming soon" features).

Subversion isn't the only open-source revision control system out there. Check out these projects as well:
OpenCM
arch
Stellation
PRCS

When the poster announced this project a little over two years ago I asked why in the world spend time developing another configuration management system with many extant, more on the horizon, and so much work left on EROS. I certainly thought OpenCM (then DCMS) would never see the light of day. I was wrong, and glad about it. I'm really looking forward to disconnected operations.