[cvsnt] BUG: different command prompts seem to have "cross-talk"

[Jim Hyslop]

Tony Hoyle wrote:
> Jim Hyslop wrote:
> > In one command prompt, I issued the command 'cvs unedit 
> -u(username) 
> > -R'. While that was running, I opened another command 
> prompt and, from 
> > the same directory, issued the command 'cvs -nq up'. The 
> output from 
> > the two command prompts seems to have some "cross talk" (to 
> borrow an 
> > electronics term).
> 
> Yeah you really can't do two operations on the same sandbox 
> at the same time... no locking...

> edit is particularly bad as it uses temp files (CVS/Notify) 
> to store its data, so anything that sees that thinks there's 
> an aborted edit operation and tries to complete it, resulting 
> in a mess.  Rewriting edit to remove that file is one of 
> those things I've got on my priority list.

Or possibly just suppressing the helpful behaviour of other commands
would do it.

> Client side locking isn't something I've really thought about 
> as cvs has never had it and nobody has complained until today 

I don't think client-side locking would really be required, at least not
in this case. One of the operations was a "read-only" operation - a
query against CVS to see what's been modified locally ("cvs -nq up").
The other operation affects only the server. Nothing was being changed
on the client side.

I've been running through various scenarios in my head, and I can't come
up with any that would require client-side locking. At least, nothing
that any sane individual should try. You could, I suppose, perform two
different, possibly conflicting, merges simultaneously (e.g. in one
window "cvs up -jbranch1 -jbranch2" and in another "cvs up -jbranch2
-jbranch1"), but ISTM no sane individual would try that. Any other
scenario I can think of offhand would be sufficiently protected by
server-side locking. Unless you want to protect against, for example, a
user simultaneously updating and tagging.

-- 
Jim