Kai Henningsen said:
> Oh, and (5) security from non-owner non-root users who might have file
> level access to the repository so they can get at parts of same. A client-
> server and/or set-userid scheme would solve this. Or you could handle that
> by putting the entire repository under a key that only the owner has - but
> the repository server needs access to that key, and the other users must
> not have access, and if your OS file-level protection doesn't give you
> that, you lose.
Yep, I'd give a thumbs-up to a client-server scheme too, (a) to deal with this issue and (b) to make the system easier to use on a network of many client machines talking to 1 repository server.
To explain (b): the idea would be that a client machine would not have to support NFS to access the repository, and would hopefully be easier to port to new platforms -- so that users of those platforms would be able to use this DCMS even if they couldn't get all the server-side repository logic ported.
BTW I'm afraid this is yet another Perforce feature ;)
I get the impression a lot of folks here are unfamiliar with p4, and IMHO it would be worthwhile taking a look at it before it's too late to nick design ideas; it has a lot of features that are a good next step from the CVS model, and it's learnt from several other systems' mistakes already. Here's a good architectural overview:
>This differs strongly from the view expressed in the tigris design. In
>general, I see no reason to capture directories as long as paths are fully
-- Justin Mason Work: http://www.netnoteinc.com/ <firstname.lastname@example.org> Personal: http://jmason.org/ <email@example.com> "It's true that some sharks get cancer. I said this in my book." -- William Lane, author of _Sharks Don't Get Cancer_