|
in reply to Re: Learning How to Use CVS for Personal Perl Coding Practices
in thread Learning How to Use CVS for Personal Perl Coding Practices
It should perhaps be pointed out that Perforce is only free as in beer, not speech, and that the Perforce Server (which is needed if you want to share the repo with more than one other person) is not free (unless you're an open-source project in which case you can get a special license).
Without wanting to turn this into an off-topic flamefest, I don't know any feature which Perforce (or any other closed-source SCM) offers that is not available from an open source one, and the Linux kernel Bitkeeper mess shows the importance of keeping one's codebase in an open format which can be readily accessed with open tools.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
|
Re^3: Learning How to Use CVS for Personal Perl Coding Practices
by spiritway (Vicar) on Nov 03, 2005 at 17:34 UTC
|
Well, as I mentioned previously, I am a complete newbie with SCCS software. I tried CVS, Subversion, and Perforce. The only system I could get up and running, that had documentation I could understand, was Perforce. Those other systems may very well be better, but since I can't figure out how to make them go, they aren't useful to me. As for Perforce not being "free as in speech", I didn't consider that an issue. Since nothing I produce would depend on Perforce, it would not affect any licensing. I agree that if you're trying to keep your machine completely "free as in speech", Perforce would not be an appropriate choice. I'm not acquainted with the "Linux kernel Bitkeeper mess". That mess (if I knew about it) might have caused me to change my mind about using a closed-source product. The Perforce Server is free (as in beer), but sharply limited (2 users, 5 client workspaces).
As it turns out, however, I finally just wrote my own script to take care of the problem of version control, and it works well enough for me that I don't have to worry about any of these programs. It just tucks my files away into time-stamped directories, so that I can find them if needed. It's not pretty, but it does the job.
| [reply] |
|
|
In brief, the "Linux kernel Bitkeeper mess" was Linus Torvalds using a proprietary (but freely available, for some definitions of freely) SCM for the main tree of the Linux kernel. At some point the SCM vendor (decided|was forced) to declare he would no longer provide the system for free. Since the vendors had issues with other people developing software which interoperated with his system, kernel development was severely impaired while Linus wrote his own SCM and worked on getting the kernel tree and history imported into that in an useful way. It appears that the "mess" set kernel development back by about a month, which is considerable. Google for "linus mcvoy bitkeeper" and take a look at the lkml archives for more details on the sordid mess.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
| [reply] |
|
|
That summary may have been too brief. You skipped the bit about Linus believing that Bitkeeper's advantages over other SCM systems saved him more than a year in the time that he did use it. So - even after the meltdown - Linus does not regret his decision to use Bitkeeper.
| [reply] |
|
|
|
|
At some point the SCM vendor (decided|was forced) to declare he would no longer provide the system for free.
You left out an important (to me) fact here: This was triggered because a member of Linus' team that was gung-ho "everything in the world should be open-source" guy wrote a reverse-engineering of the data format for BitKeeper, violating the agreement Linus had with Larry, even over Linus' persistent and deliberate advice to the contrary.
So, part of the story is "even if you're an open-source zealot, follow the rules!"
On the other hand, from lemons came lemonade. I'm strongly considering using Git on projects because of its nice distributed creativity model. (No, I can't seem to get SVK to work on my machines, and the rest of the stuff looks even further down the scale. Git compiles and installs trivially, except for the documentation stuff.)
update: yes, sorry, I misheard the story. Not a "member of his team", but perhaps someone who should have understood the consequences of his act.
| [reply] |
|
|
|
|
|
|
Wow, I can see where this would have been a total meltdown. That's a very compelling reason not to use Perforce, so I have to agree - it's only free as in beer. I think I'll uninstall it myself, now... thanks for the info.
UPDATE:Someone asked me whether this comment had been sarcastic. Not at all. The debacle as described was a prime example of why it wouldn't be a good idea to use non-open source software for version control. Knowing this, I have changed my mind about using Perforce, and will indeed uninstall it.
| [reply] |
|
|
