[EMAIL PROTECTED] on 2000.02.25 18:16:18
>[ On Thursday, February 24, 2000 at 20:50:24 (-0500), Noel L Yap wrote: ]
>> Subject: Re: removing the need for "cvs add file" to contact the server....
>>
>> [EMAIL PROTECTED] on 2000.02.24 17:17:25
>> >[ On Thursday, February 24, 2000 at 13:34:36 (-0500), Noel L Yap wrote: ]
>> >> The manual doesn't mention ACL's
>> >> at all.
>> >
>> >Hmm.... I wonder what that could mean!
>>
>> Are you implying that noone should use ACLs within the repository? I thought
>> CVS and permissions were orthogonal (except where they intersect ;-)?
>
>It means using CVS with filesystem ACLs in the repository may lead to
>undefined behaviour. I.e. you're on your own.
OK, that's fine. However, CVS shouldn't try to make it difficult (as you're
proposing) to use tools that aren't explicitly mentioned in the manual.
>> >> Does this mean that they shouldn't be used? Should I also not use
>> >> emacs 'cos the manual doesn't mention it?
>> >
>> >No, of course not -- it may mean that you can't use them with CVS
>> >though, at least not without some additional support tools....
>>
>> It means no such thing. So long as there's a process that allows both to be
>> used, there's no problem using them. We've already outlined such a process.
>> You now claim that that process is dependent on a bug. I claim that "cvs
add"
>> and "cvs ci" support for empty hierarchies isn't a bug.
>
>Ah, sorry, "BZZZZZT", but you're wrong. Several people have shown this
>several times already.
No, Greg. Some people have claimed it (mostly you). Noone has *shown* how this
is harmful, specially in lieu of the fact that CVS already supports it.
Furthermore, noone has proven that special handling of empty hierarchies by "cvs
add" is *necessary*. Please show explicitly how this is dangerous.
If you say, "People'll think directories are versioned", I'll answer, "Educate
them".
>> You still haven't addressed the issue of "mkdir -p dir1/dir2; cd dir1; touch
>> dir2/file; cvs add dir2; cvs rm dir2/file".
>
>I have. You haven't paid attention, possibly because you didn't like
>the answer.
I guess I missed it. Can you go over it again?
>> Your proposal mentions nothing of
>> "cvs rm" going up directories trimming off CVS admin subdirectories off empty
>> hierarchies.
>
>That's clearly outside of my proposal.
Fine. So now you have CVS admin directories existing within local empty
hierarchies. It seems that "cvs ci" will now have to check whether the
hierarchies are empty before it actually creates it within the repo. IOW, both
"cvs add" and "cvs ci" will check for empty hierarchies. This doesn't sound
like a good optimisation to me.
So, if I'm missing something, can you explicitly go over it?
>However in case you haven't tried it in real life yet, I will point out
>that the handling of this case is already well defined by "cvs update -P"
God dammit it, Greg. This is exactly what I've been saying all along!!! YOU
HAVEN'T BEEN PAYING ANY ATTENTION!!! ONCE AGAIN, _*ONLY*_ "cvs co", "cvs
export", and "cvs up" should be dealing with empty hierarchies. Neither "cvs
add", "cvs ci", nor "cvs rm" should be doing any such thing. Get some sleep and
reread this paragraph until it sinks in, will you???
God dammit it, Greg. This is exactly what I've been saying all along!!! YOU
HAVEN'T BEEN PAYING ANY ATTENTION!!! ONCE AGAIN, _*ONLY*_ "cvs co", "cvs
export", and "cvs up" should be dealing with empty hierarchies. Neither "cvs
add", "cvs ci", nor "cvs rm" should be doing any such thing. Get some sleep and
reread this paragraph until it sinks in, will you???
I figure I might at well copy and paste it now, maybe I'll avoid doing it later.
>> Such a scheme would have to test each ancestor directory until it
>> found one that's not empty (which may mean that at least one of their
>> subdirectories isn't empty).
>
>I proposed no such scheme.
No you didn't. So, how will "mkdir -p dir1/dir2; cd dir1; touch
>> dir2/file; cvs add dir2; cvs rm dir2/file" be handled? Since you're saying
"cvs rm" won't specially handle empty hierarchies, there'll be local empty
hierarchies with CVS admin directories lying around. Why not just let "cvs add"
allow this?
If you say that "cvs add" shouldn't allow this, but the situation can still
occur (ie the variant is violated), then this is more of a bug than just
allowing "cvs add" to create CVS admin subdirectories within empty hierarchies.
>> You also claim that no CVS commands treat directories specially. I've
already
>> said that "cvs watch dir" treats dir specially. There's no reason why "cvs
add
>> dir" (when dir is an empty hierarchy) is dangerous in that it'll lead others
to
>> believe directories are versioned.
>
>It does not. It simply operates on all the files in the directory,
>current or future. I've explained this at least twice now.
BS. Stop spreading lies Greg. "cvs watch dir" specially marks the directory as
being watched so that newly added files and created directories will also be
watched. I think your non-scientificness (word?) is shown by guessing the
behaviours of features you don't use.
>> >Well, given that I described a way that you could use still manage to
>> >use ACLs with CVS it would seem you're spouting nonsense here....
>>
>> Again, those other solutions require too much overhead.
>
>Then follow my initial suggestion and simplify your requirements. A
>proper risk assesment is almost guaranteed to do this for you.
<sarcasm> Yes, Greg. I'll bend my requirements to fit the tool. </sarcasm>
>> >If you can define the rules then they can be automated. Obviously such
>> >maintenance of access controls requires privileges that span all of the
>> >rights being assigned, whether the task is automated or not.....
>>
>> I've defined the rules:
>
>Those are not the kinds of rules I was talking about. Define the
>security policy. You'll have to do a risk assesment first though if you
>expect to be able to do a sensible job of that.
OK, once again, then. The original problem: We have one group that needs
checkout/commit priveleges to the entire repository. We have some other groups
that needs checkout priveleges to the entire repository, but only commit
priveleges to some modules. The cvs admin must be free to grant/deny groups
permissions into the repo at will (ie without sysadmin help other than creating
those groups to begin with).
>> Therefore: In order to maintain and manage the permissions within the repo,
at
>> least all directories must be owned by the cvs admin. The simplest way to
>> achieve this is to have only the cvs admin create directories within the
repo.
>
>Your conclusion is wrong.
<sarcasm> Gee, I just love your terse comments. They add sooo much value to
this noisy thread. I think I'll add my own terse comment. You're post has no
value. </sarcasm>
