On Wed, 30 Dec 1998, Christopher G. Petrilli wrote:

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... That's why storing the website as a file tree is so nice :)

Most of the tools one wants to use know how to deal with file trees :)

...

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. Nope. He just states ``sane'' requirements for doing projects. It's more or less the same as with SQL. I personally detest SQL, and many collegues working in the sector hate it too. After using BoboPOS for a small project, and my experiences with it, I just sounded one question to my collection of SQL haters: Where would they store legally important (for example invoices, etc.) data. Funny thing, every one of them admitted that he would store it in a good proven SQL server, and wouldn't even consider a OODB.

Having been in a philosophical mood then, I thought a bit, and discovered, that the full integration of data and code in OO programming is not right for certain data, especially when the client is required to keep the data longer (by law) than he will probably keep his hardware and software. (Doctors for example have to keep their records here around for 10 years safeguarded, ..., accounting stuff must be kept for 7 years, etc. That are time spans, that in the fast moving IT world nowadays can mean that there will be more than one software that will have to access the same data: Basically, the data scheme and data itself is much more static than even software. In some cases this leads to ``new'' mainframe sales nowadays: Nobody knows how the data is structured (and what implicit assumptions are in the code/data), nor can anybody really understand the software, so when the hardware breaks, new (exactly the same) hardware is bought as a replacement.)

...

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: See above. Certain data must be as freely as possible available. And BoboPOS implies: a) that the live production data is locked in somewhere. b) that there certain things done that are badly mappable to a filetree. (Easy one: How do you express references to the same object? symlinks? Wrong answer, because there is no master reference all references are the same. hardlinks? Wrong answer, how do you hardlink directories, ... ) And there are many other things like this.

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?

Exactly *g*

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.

Not really. The problem is that some people consider website development as software development, especially if you go further than a couple of nice static webpages. Now if you just want static webpages, than you can stay with a standard webserver, right? Proven software. Now if you do develop some code, you'd better treat it as a software developement project. And SQL queries are to classified as code. (I've seen projects where the SQL ``programmer'' that supplied about 10 queries was better paid than the programmer who did all the grunt work.) Oops, Zope now does SQL, right? So Zope better meet the same ``sane'' requirements for software development. The problem here is, that for most projects the maintenance is the deciding factor. Sometime you can bring in ``exotic'' solutions like Python through arguments like productivity, price, etc., sometimes it just doesn't matter that our solution will be: 1.) quicker to deploy, 2.) cheaper, 3.) more stable, etc., just because the client never heard of python and doesn't know anybody else around here who could maintain python code. Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.