[ On Monday, January 31, 2005 at 01:18:36 (-0800), Paul Sander wrote: ]
> Subject: Re: 'cvs add' client/server semantics (was Re: Triggers)
>
> 'Course, Greg has claimed in the past that he already has a patch...
Actually, no, I have never made any such claim.
I've posted everything I have done so far save for a few tiny hacks that
are incomplete and inappropriate for general use.
> I have some questions for Greg regarding his patch: Assume the
> repository contains a directory tree foo/bar. Both directories contain
> files. The user performs the following sequence of commands:
>
> cvs checkout -l foo
> cd foo
> mkdir bar
> cvs add bar
> cd bar
>
> At this point, is the workspace in a state in which the user can
> successfully invoke the "cvs add" and "cvs update" commands on new and
> existing files contained by the bar directory, before the next commit?
Well yes, I should certainly hope so.
The first command should have created a "D" entry for the "bar"
directory in the CVS/Entries file even though that directory was not
initially created in the local workspace. This doesn't happen with the
current implementation, but it probably should. Doing this may require
cleaning up and adjusting some internal error checking in the client
too, but that's just an implementation detail.
The "cvs add" at that point would have created the admin files in the
"bar" directory and marked it as being a local instantiation of an
existing directory -- thus other local working directory operations
would know that the content of the directory was still unknown locally.
(this would likely require some new admin file or flag somewhere, but
that's also just an implementation detail)
> What happens if a user invokes "cvs add" to create a file that already
> exists in the repository but not in the workspace, given that the
> client has conjured up its own metadata about the bar directory?
>
> Seems to me that it should just work, but I have to ask. :-)
Well the "new" local file will be marked as added to the local directory
so that a subsequent "cvs commit" will try to commit it as a new file.
However since the file does already exist in the repot the result will
be the simple standard ``Move "bar" out of the way, it already exists''
kind of error.
A "cvs update" (or even "cvs update bar") would also generate the same
error/warning of course, so the user can find out about the conflict at
his or her leisure and without having to have been connected at "cvs
add" time.
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL
PROTECTED]>
_______________________________________________
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
