Contributed by jose on from the alternative-to-cvs dept.
(Comments are closed)
OpenBSD Journal
Contributed by jose on from the alternative-to-cvs dept.
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By Dweebster () on
http://subversion.tigris.org/
Comments
By Anonymous Coward () on
the licensing is not compatible. Hopefully similar
problems will be avoided by the OpenCM developers.
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
is under the Sleepycat License which is not a
BSD friendly license.
By Anonymous Coward () on
I don't want to install apache if the machine isn't going to be a webserver, so this SUX!
Comments
By Anonymous Coward () on http://dict.org
By Anonymous Coward () on
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=212130
By Tobias Weingartner () weingart@tepid.org on http://www.tepid.org/~weingart/
1 - A decent object store is absolutely essential in OpenCM. This includes a way to import and export portions (or all) of it to a portable and editable format. (In this way object stores can be imported/exported between versions, etc...)
Of course, KISS is the best principle. If you use XML, keep it simple XML. Don't use every fancy feature in it, etc. Note, you then only need to provide a tool per CM system to import/convert to your tool. A 'la RPC...
2 - Ability to operate on portions of a tree. I do many things within my tree, being able to commit, etc on only a portion of a tree is entirely essential. If I want to operate on the whole tree, I can always tell OpenCM to do so.
3 - Speed. OpenCM is currently slow. Diskspace is pretty cheap, use it to get better speed and throughput.
4 - Documentation. The documentation does not match the implementation. Either find a way to grow both in step, or write the documentation first. This will help in figuring out what you want to call commands, etc. It will help in fleshing out the overall structure of the CM system. This it seems has not been done.
5 - Don't depend on libGC. Use standard ANSI/ISO C, and write your own libraries to keep it portable. Only use other libraries for the object store (if necessary). Keep the client as portable as you can. Don't go overboard (like CVS/apache), but code to the standards.
6 - Organize and create development boundaries wrt API and interfaces. Define these API's, and then code to them. In this way more people can code up portions of the system. (IE: if you have a published API for the object store, someone could do a research implementation of some new idea, which could pay off in the end...)
I'm sure there are more, but I'm drawing a blank on the rest right now.
-T.
Comments
By Dan Weeks () danimal [AT] danimal [DOT] org on mailto:danimal [AT] danimal [DOT] org
putting effort into third party libs means your fixes and the fixes of other benifit many more people than just your project.
of course you say you're not a developer, so I'll assume you might not fully understand all aspects of this. grain of salt taken.
Comments
By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org
He said that `he doesn't code', which means that he isn't
writing code *currently*, but he certainly know what he's
talking about.
And, we're not talking about any other libraries. There are
good reasons to think using a GC in opencm might be a big
mistake (especially as this GC turns out to be a bitch to
debug).
All of Toby's points make sense.
By Tobias Weingartner () weingart@tepid.org on http://www.tepid.org/~weingart/
Now, libgc, while a worthwhile library on it's own, does not make much sense in the light of POSIX systems. Just clean up your memory already. C was not really meant for garbage collection...
Or my favourite, glibc. Why do you need all those wrapper functions for standard ANSI/ISO C? Just code to the standards already. Exceptions (and bugs) are few and far between today. And when they do occur, make it a point to tell the vendor about it. Push the vendor to fix it. Don't settle for mediocrity in other people's software by "adapting" yours to fit.
Again, just my $0.02.
-T.
Comments
By Dan Weeks () danimal [AT] danimal [DOT] org on mailto:danimal [AT] danimal [DOT] org
i'll agree with you on glibc, bleh. I'm just now looking at libgc and Marc's right, all of Tobias' comments make sense.
My apologies for jumping the gun there.
By James Frazer () jfrazer@shaw.ca on mailto:jfrazer@shaw.ca
Listen to Tobi, he knows what he's talking about.
;-)
Comments
By Dan Weeks () danimal [AT] danimal [DOT] org on mailto:danimal [AT] danimal [DOT] org
:)