--- Paul Sander <[EMAIL PROTECTED]> wrote: > >OTOH, it might be nice if such a command were > >introduced anyway. > > It's already needed; how many times have the execute > bits been > set incorrectly for various files? I was figuring > on adding > at least this capability anyway.
Well, if we're thinking of mapping files and directories to random archive names, we'll definitely need to add a sort of "cvs chmod" command. > I still need to be educated on how > filesystem-supplied ACLs > work on various Unix systems, but I'm under the > impression > that their implementations are proprietary and > non-portable. > This makes for a compelling reason not to support > them. AFAIK, they conform to a POSIX standard. > On the other hand, assuming that ACL implementations > can be > abstracted out reasonably well, perhaps we can cut > back on the > bookkeeping by ignoring certain aspects of ACLs. We > could, for > example, require that owners have write permission, > and store > execute permissions as attributes on the RCS files. > We could > also treat world read access as an attribute and > world write > access would negate the need for any ACL tracking at > all. > So, we narrow down to just three cases: Owner-only > access > (an easy special case), world write access (another > easy special > case), and tracking group read/write access using > your method. > For source control, I think that the execute bits > can match read > bits for those cases where execute access is needed > (hence the > attribute). I see no reason not to leave this responsibility to the file system. If the file system doesn't support ACL's, then the CVS implementation won't either. Noel __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/ _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
