cvs editors funny
Hi folks, 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. 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. Anyone else come across this ? Cheers Colm A ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs editors funny
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. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs editors funny
On Mar 24, 2005, at 7:00 AM, [EMAIL PROTECTED] 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" [EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs editors funny
Paul Sander wrote: > 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, [etc] Thank you for corroborating how difficult this would be to accomplish :-) To summarize: - you have to come up with a way of uniquely identifying each and every unique checkout. This includes scenarios such as: cvs co projname cd projname cvs edit filename cd .. rm -rf projname cvs co projname Two distinct checkouts, into the same location. - You have to manage these unique IDs, and maintain the correlation between the ID and the local directory - You have to come up with an administrative interface to manage manually removing edits to handle corner cases like the one above (or even the case above, without the second 'cvs co' command) I didn't say it couldn't be done, but I did hint that it would be a complicated job. To implement this feature would take a lot of thought and planning. A lot more than a simple patch to correct the "editors disappear on a checkout" bug that Darren fixed. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs editors funny
Hi Jim, The current cvs edit command stores the users name and workspace location in the fileattr file. I'm guessing that when you unedit or checkin it it only matching the users name and not the workspace location. How difficult would it be to check the users name and workspace location and only remove the edit if it matches ? We do find that old edits hang around when uses forget to use unedit and just remove the workspace. This isn't a major pain as you can just edit the fileattr to remove the unused edits. Regards Colm A Jim.Hyslop wrote: Paul Sander wrote: 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, [etc] Thank you for corroborating how difficult this would be to accomplish :-) To summarize: - you have to come up with a way of uniquely identifying each and every unique checkout. This includes scenarios such as: cvs co projname cd projname cvs edit filename cd .. rm -rf projname cvs co projname Two distinct checkouts, into the same location. - You have to manage these unique IDs, and maintain the correlation between the ID and the local directory - You have to come up with an administrative interface to manage manually removing edits to handle corner cases like the one above (or even the case above, without the second 'cvs co' command) I didn't say it couldn't be done, but I did hint that it would be a complicated job. To implement this feature would take a lot of thought and planning. A lot more than a simple patch to correct the "editors disappear on a checkout" bug that Darren fixed. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs editors funny
Colm Aengus Murphy wrote: > The current cvs edit command stores the users name and workspace > location in the fileattr file. I'm guessing that when you unedit or > checkin it it only matching the users name and not the workspace > location. How difficult would it be to check the users name and > workspace location and only remove the edit if it matches ? Huh, whaddya know - it looks like CVS already captures that information. I issued a 'watch on' and 'edit' on a .cvsignore file, and the fileattr contains: F.cvsignore _watched=;_editors=jhyslop>Tue Mar 29 14:13:46 2005 GMT+01-2189+E:\cvs\cvs-test\jhyslop;_watchers=jhyslop>tedit+tunedit+tcommit The datestamp and path are displayed when you issue 'cvs editors'. It only stores one per user, though - I checked out the project into a different directory, issued the 'cvs edit' command and got: F.cvsignore _watched=;_editors=jhyslop>Tue Mar 29 14:16:07 2005 GMT+01-2189+E:\cvs\cvstest2;_watchers=jhyslop>tedit+tunedit+tcommit So the infrastructure may be there already. It may not be as difficult as I thought. > We do find that old edits hang around when uses forget to use > unedit and > just remove the workspace. This isn't a major pain as you can > just edit > the fileattr to remove the unused edits. Ick - I hate having to manually edit the file (we have a lot of people who have left, but forgot to 'cvs watch remove' before they left). One of these days, when I have the time, I'm going to work on implementing rwatch and redit commands, with options to specify the user. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs editors funny
Be careful here. The location appears to the directory identified by the client at the time the edit was done. Due to network mounts, this path is not unique. So when editing, unediting, or committing a file, there's really no way to know if the workspace you're affecting is really the one recorded by a prior edit. On Mar 29, 2005, at 6:22 AM, [EMAIL PROTECTED] wrote: Colm Aengus Murphy wrote: The current cvs edit command stores the users name and workspace location in the fileattr file. I'm guessing that when you unedit or checkin it it only matching the users name and not the workspace location. How difficult would it be to check the users name and workspace location and only remove the edit if it matches ? Huh, whaddya know - it looks like CVS already captures that information. I issued a 'watch on' and 'edit' on a .cvsignore file, and the fileattr contains: F.cvsignore _watched=;_editors=jhyslop>Tue Mar 29 14:13:46 2005 GMT+01-2189+E:\cvs\cvs-test\jhyslop; _watchers=jhyslop>tedit+tunedit+tcommit The datestamp and path are displayed when you issue 'cvs editors'. It only stores one per user, though - I checked out the project into a different directory, issued the 'cvs edit' command and got: F.cvsignore _watched=;_editors=jhyslop>Tue Mar 29 14:16:07 2005 GMT+01-2189+E:\cvs\cvstest2;_watchers=jhyslop>tedit+tunedit+tcommit So the infrastructure may be there already. It may not be as difficult as I thought. We do find that old edits hang around when uses forget to use unedit and just remove the workspace. This isn't a major pain as you can just edit the fileattr to remove the unused edits. Ick - I hate having to manually edit the file (we have a lot of people who have left, but forgot to 'cvs watch remove' before they left). One of these days, when I have the time, I'm going to work on implementing rwatch and redit commands, with options to specify the user. -- Paul Sander | "When a true genius appears in the world, you may [EMAIL PROTECTED] | know him by this sign: that all the dunces are in | confederacy against him." -- Jonathan Swift, writer. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: cvs editors funny
Paul Sander wrote: > Be careful here. The location appears to the directory > identified by > the client at the time the edit was done. Due to network > mounts, this > path is not unique. So when editing, unediting, or > committing a file, > there's really no way to know if the workspace you're affecting is > really the one recorded by a prior edit. True, but is that significantly different than the following scenarios: cvs co project cd project cvs edit file cd .. mv project proj2 or: cvs co project cd project cvs edit file cd .. rm -rf project Or am I missing something? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs editors funny
No, it's not. But in your last message you seemed rather upbeat about finding the path of the workspace having been squirreled away. I'm just pointing out that you can't hope for a solution to this problem unless the workspace and repository can both agree on an identity for the workspace. Comparing the present working directory of the client with a stored workspace path will likely not satisfy this requirement. Storing the present working directory of the client in the workspace at the time it was created, and using that stored value, would satisfy the requirement. On Mar 30, 2005, at 7:08 AM, [EMAIL PROTECTED] wrote: Paul Sander wrote: Be careful here. The location appears to the directory identified by the client at the time the edit was done. Due to network mounts, this path is not unique. So when editing, unediting, or committing a file, there's really no way to know if the workspace you're affecting is really the one recorded by a prior edit. True, but is that significantly different than the following scenarios: cvs co project cd project cvs edit file cd .. mv project proj2 or: cvs co project cd project cvs edit file cd .. rm -rf project Or am I missing something? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) -- Paul Sander | "Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones" -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
