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.
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:
http://www.perforce.com/perforce/bullet.html http://www.perforce.com/perforce/doc.992/manuals/p4guide/01_concepts.html
Regarding directories:
>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
>recorded.
I agree.
--
Justin Mason Work: http://www.netnoteinc.com/ <jm@netnoteinc.com>
Personal: http://jmason.org/ <jm@jmason.org>
"It's true that some sharks get cancer. I said this in my book."
-- William Lane, author of _Sharks Don't Get Cancer_