Yes, IMO this is a bug.  The original implementor didn't know how to get edits
(or, more precisely unedits upon commit) to work properly when the same editor
edits the same file within more than one working directory.  I'm working on
fixing this.  I should have something posted by the end of the week (it would've
been out last week, but I've been out sick the last few days).

Noel

PS
For those interested, the difficulty was that, on client/server by commit time,
there was no way to know what the location (ie hostname and working directory)
of the file was.  So, if edits were stored as "user@hostname:/working_dir",
unedits would work fine, but uneditting upon commit wouldn't.




[EMAIL PROTECTED] on 2000.04.03 13:53:39

To:   [EMAIL PROTECTED]
cc:   [EMAIL PROTECTED]
Subject:  CVS bug?




Noel,

I noticed in the cvs newsgroups that you have responded to a number of the
cvs issues relegated to the editors and watch features. I'm trying to figure
out if I've stumbled across a bug or if my usage model is incorrect.

> We're using CVS version 1.10.7 and we're using the editors and watch
> features. So we've done a "cvs watch on" on all of the files and everytime
> someone wants to edit a file, they do a "cvs edit <filename>" first. That
> way the "cvs editors" command can be used to see who else might be editing
> the same file.
>
> Right now, we're having troubles with CVS losing the editors information.
> I've been able to duplicate the problem using WinCVS and the command line
> version of CVS. The following scenario duplicates the problem:
>
>  mkdir foo1
>  cd foo1
>  cvs checkout scripts
>  cd scripts
>  cvs edit foo.pl
>  cvs editors <-- indicates that foo.pl is currently being edited. mkdir
> foo2
>
>  mkdir foo2
>  cd foo2
>  cvs checkout scripts
>  cd scripts
>  cvs editors <-- indicates that foo.pl is currently NOT being edited.
>
> I looked at the fileattr file in the repository before and after the
> checkout was done in the foo2 area and it appears that the watch
> information is being blown away from inside that file.
>
Does this sound like a bug?

> Thanks.
>
> Rob
>





Reply via email to