Re: cvs editors funny

[Paul Sander]

On Mar 24, 2005, at 7:00 AM, address@hidden wrote:

> Colm Aengus Murphy wrote:
> > We've come across the following funny when using the cvs
> > editors feature.
> > In my workspace I do a "cvs edit" to indicate I am editing a file.
> > "cvs editors" correctly reports me as an editor.
> > If I then create another workspace using "cvs co" and run
> > "cvs editors"
> > I am no longer listed as an editor of the file.
> Darren Bowles submitted a patch to correct this, on the bug-cvs list, 
> two
> days ago. Is this a good demonstration of statistical clustering, or 
> what?
> :=)
>
> > Another funny is that you can only be listed as an editor of
> > a file once
> > even though you might be editing the same file in more than
> > one workspace.
> Well, this one's a bit trickier. The repository does not keep track of 
> how
> many locations you have a workspace checked out (except _maybe_ in the
> history file). Seems to me keeping track of which locations you're 
> editing
> and which you aren't would be an administrative nightmare, getting into
> situations that could be extremely difficult to correct. For example,
> suppose a user checks out a project, issues 'cvs edit' on one or more 
> files,
> then abandons the changes by simply deleting the working copy. In 
> order to
> release the edit, the user would have to re-create the exact same 
> directory
> structure, then issue the 'cvs unedit' command.

You don't have to store the actual locations in the repository.  (Doing 
so is pointless anyway given that mount points can appear and disappear 
non-deterministically.)  Just store an identifier there, which could be 
as simple as an Ethernet-address/timestamp/pid triple.  (I suggest 
Ethernet address because it's guaranteed to be unique to the interface, 
and Ethernet is pretty common.

It doesn't really matter what the identifier is, as long as it's 
unique.  The server could also conjure one up when the client creates a 
new workspace.)  The identifier must be stored in the workspace as 
well.  In the event that a workspace references multiple repositories, 
it can have multiple identifiers matching each repository.

Yet another approach would be to generate the identifier on the client 
from the host's FQDN and fullpath to the top of the workspace at the 
moment the client creates it.  It won't necessarily be the actual 
location where the user did any specific edit, but solves the 
requirement of tracking edits per workspace, and it also provides a 
means to start searching for a workspace should it be necessary.

When listing editors, users may be listed multiple times, and 
identifiers matching the user's workspace can be highlighted (or 
identifiers not matching the workspace can be omitted).  When unediting 
or committing work, remove the edit record matching the user and the 
workspace identifier.  When removing a workspace, remove all edit 
records matching the workspace identifier.  Provide administrative 
functions to list editors with workspace identifiers and to remove 
editors matching a specific workspace identifier.
--
Paul Sander       | "To do two things at once is to do neither"
address@hidden | Publilius Syrus, Roman philosopher, 100 B.C.