On Wed, Dec 30, 1998 at 09:45:09AM -0800, Curtis Galloway wrote:
I realize that my previous message was slightly inflammatory. In an effort to be constructive, here is my minimum set of requirements for any project development system:
I'll say this up front, which is that if you have hard and fast rules about how things must behave to be "usable" and a system doesn't mean those rules, why don't you just move on, rather than trying to spin the world into your own orbit? THis isn't an attack, just an observation... many people have their own views and they're all equally valid, but that doesn't mean there's only one...
1. The source code should be represented as plain ASCII files.
I'd modify this to: "The source code must be accessible as plain ASCII".
2. All required actions must be automatable.
This is very vague... I could write a program today that used HTTP to do all the things you need to do through it... but I agree that Zope needs lots of work in this area
Corollaries to requirement 1: you can edit source files with your favorite editor, diff them, and store them in your favorite source code control package.
This will probably NEVER be doable, even Emacs stumbles over various VC models... I don't want to end up supporting RCS, CVS, SCCS, CodeSafe, SourceSafe, and about 20 others that I've used/seen...
By "source code" I mean all the information you create for your project: C, Python, HTML, documentation, whatever. If there is meta-data that is required to make your project work, it should be stored in a human-readable form as well. An example of this might be permissions on files, which would be stored in the form of a Makefile rule that sets the permissions..
Um, is it me or are you generalizing Zope out to full version control and project management for everything known to mankind? It's intended to manage objects, period, some objects are DTML, some are Python, some are all kinds of things... but I've never seen one for C.
Corollaries to requirement 2: you must be able to build and maintain your project with command-line tools. Being able to use a GUI or a web page to do things is great, but there is no substitute for the UNIX way. Windows NT is a good counter-example to this rule.
I agree that there need to be CLI interfaces to shoving thigns into the object database, and getting them out. BUT, there's nothing saything that the following options aren't 100% valid and workable, if you're willing to make slight compromises: 1. FTP access 2. Theoretically you could build a VFS interface and MOUNT the object database. I did this once with Versant, it is possible.
Here are some examples of project tasks that are facilitated by these basic two requirements:
- I want to be able to take a snapshot of my whole project that I can roll back to at a future date.
This is doable currently, though perhaps not well documented.
- I want one team of people to work on part of the project independently without clobbering what another team is doing.
How do the current draft and session management tools fail at this?
- I need to look at the diffs between yesterday's version of the project and today's version to figure out what person X did.
This needs to be available, it's just a matter of grabbing the revs and diffing them.
- I want to set up an automated task to check out the latest version of the project from source control and build it on a test machine.
Um, what does this have to do with Zope? I'm confused, all this seems more concerned with software development than website, and while there some of the former in the latter, they're not fully inclusive of their requirements. I don't expect one widget to do everything for me. I do my Product development in RCS, even though the website uses the Zope databse to storee things in. I'm just affraid you've made this a MUCH larger issue than it is. Chris -- | Christopher Petrilli | petrilli@amber.org