[EMAIL PROTECTED] on 03/01/2000 09:43:02 PM
>[ On Wednesday, March 1, 2000 at 09:50:06 (-0500), Noel L Yap wrote: ]
>> Subject: Re: removing the need for "cvs add file" to contact the server....
>>
>> Yes, I know. However, they are created and acted upon by CVS. Our
differences
>> lie in what conditions they should be created.
>
>Please be very very very careful with your terms! "Managed" in this
>case (i.e. in any context where the function of CVS is being discussed)
>means "version controlled"! Directories are not "managed" -- they are
>simply created and deleted as necessary to contain the files that are
>managed. This has been explained by myself and others many many times
>already.
So has the alternate (correct) view that "managed" means "managed" and "version
controlled" means "version controlled". I'm not the one trying to say that
"grey" means "black", you are.
>> Let's go over it again. All that "cvs add" will do is to create CVS admin
>> subdirectories. I say it should do this whether or not the hierarchy is
empty.
>> If "cvs add" checks for empty hierarchies, it'll do a lot more processing
than
>> if it didn't.
>
>Sorry, but that's just simply not possible without destroying the
>current optimisation that many people rely very very heavily on.
OK, exactly what optimisation are you talking about? Why should "cvs add
empty-hier" behave differently from "touch empty-hier/file; cvs add empty-hier;
cvs rm empty-hier"?
>Besides, there's simply no reason to do it either (besides your mistaken
>disire to do strange and silly things inside your repository with
>unsupported features of your filesystem).
You're confusing issues here. "cvs add" only affects the working directory, not
the repository. There's absolutely no reason to have your "optimisation".
> Directories need only exist
>to hold the files being managed. Building some kind of nonsensical wart
>onto CVS so that it can create unnessary directories is simply wrong.
Then this is an argument for "cvs ci", not "cvs add", not to create empty
hierarchies in the repository.
>> I expect "cvs add empty-hier" to create CVS admin subdirectories. It must be
>> equivalent to "mkdir dir; touch dir/file; cvs add dir; cvs rm dir" (where
"dir"
>> is "empty-hier" of course). I don't understand how you can disagree with
this.
>> The local directory doesn't affect anyone.
>
>"cvs rm dir" doesn't do anything either if there are no files to remove!
>CVS does not manage directories -- it manages files.
Please reread the post. "cvs rm dir" will do something 'cos there are files
within the local directory to remove. With your proposal, "cvs add empty-hier"
won't create CVS admin directories, but "touch empty-hier/file; cvs add
empty-hier; cvs rm empty-hier" will.
>> I expect the following "cvs ci" to create those directories within the repo.
>
>Sorry, no can do. "cvs ci" operates only on files. The directories
>necessary to contain those files will appear in the repository *ONLY* as
>they are required. No files, no directories. It's really quite simple.
Fine. As I've already said, we differ on this issue. You say directories are
there to contain one or more managed files. I say directories are there to
contain zero (at least temporarily) or more managed files. Post your changes,
I'll fix them for our needs.
>> There is absolutely no reason why this cannot be.
>
>Yes, there is -- it lends to the impression that CVS manages directories
>when it cannot.
The solution for misimpressions is education. Guns should allow you to shoot
yourself in the foot, not have trigger locks without keys.
> Besides it's 100% unnecessary, despite your ramblings
>about wanting to do weird and unsupported things in the repository.
You keep saying it's necessary without supporting those statements. Again, how
is it *necessary*.
>> I understand how you can
>> disagree with this.
>
>Then quit trying to argue with nonsense!
Who's arguing? I've already said for you to go ahead. I'll fix what we need
fixed and post those fixes for those who want them?
>> However, as I've pointed out before (and you've totally
>> ignoredp) CVS does have one command ("cvs watch") that acts on directories,
not
>> just the files within those directories.
>
>"cvs watch dir" does *NOT* operate directories!
Yes it does. I've already explained why it does. Can you explain why you think
it doesn't?
> You are failing to
>understand the temporal nature of CVS (its most central reason for
>being!). This command does in fact operate on the files in a directory,
>and indeed not just on those that exist today, but those that might
>exist at any time in the future while the "watch" is still in effect.
In order for it to work on future files and directories, it must operate on
directories. It's like the setgid bit on directories.
>Just because a file does not yet exist in a "watched" directory does not
>mean that the file is not implicitly being watched. This is even
>reasonably clearly documented!
Right. The way it's watched is 'cos the directory is operated on.
>> <rhetorical_question> Then why allow directory names to be specified within
>> .cvsignore? </rhetorical_question> Regardless of what you say, CVS does know
>> about and act on directories. It's true that it doesn't version them but
this
>> has nothing to do with not being able to create them explicitly.
>
>That doesn't have to be a rhetorical question. The answer in fact is
>that Once again it is a simple optimisation that can lend great benefit
>to all future CVS commands run in a workspace containing a sub-hierarchy
>rooted with a directory having the "ignored" name.
Then there's absolutely no need to have your redundant "cvs add" optimisation.
>Yes of course CVS acts on directories. However it does not *manage*
>directories in the same sense that it manages the files they contain --
>it simply creates and deletes directories as is necessary to contain
>those files which it does manage. Directories are the invisible
>structure that gives form to a module. They are made to come and go as
>necessary by CVS in order to hold the files in the desired structure.
I have no argument with this in general. My argument is that only "cvs co",
"cvs export", and "cvs up" should deal with this issue. You seem to think that
all CVS commands (at least "cvs add") should at least do a half-hearted job of
trying to prevent working on empty hierarchies.
Noel
