[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs editors funny

From: Paul Sander
Subject: Re: cvs editors funny
Date: Thu, 24 Mar 2005 09:54:58 -0800

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]