Bugzilla – Full Text Bug Listing
| Summary: | [CVS Core] Update on folder deletion does nothing | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Valenta <Michael.Valenta> |
| Component: | Team | Assignee: | Platform-VCM-Inbox <platform-vcm-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P4 | CC: | andreas.krueger |
| Version: | 2.0 | Keywords: | usability |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Michael Valenta
I'm a Eclipse user, not a member of your team, but I've also been a CVS admin for some time and so I take the liberty to comment on this one. "Deleting a folder on the CVS server" is not a defined operation on a CVS repository. If you delete a file the proper way, CVS remembers the fact that the file has been there. If you check the whole thing out with a snapshot date at a time when the file was there, you do get it back with the content fitting to your snapshot date. Incidently, that's what those files in the directories "Attic" in the repository are for. The fact that a file is dead, from the main stream's point of view, is remembered by the file itself, *not* just by the fact it's been moved to the "Attic". It's well known in the CVS community that you bring undefined behavior of various amnesia kinds over your own head, if you simply delete files or directories from a CVS repository. For a full scale CVS wizard, the right way to cast the CVS amnesia spell: You first delete from all hard disks all workspaces that reference the particular part of the repository you want to subject to your spell. Only then you may go forth and remove those files. After the smoke settles, everybody has to check out anew from scratch. The net effect is a rewriting of history - the files you deleted never existed. As for this bug, in my opinion it should be resolved as "invalid". Andreas, What you say is true. However, the fact remains that I can delete a folder directly from the server and I don't need to tell anyone. Itwould be nice if the client handled this in some way. We may end up doing what you suggest and mark the bug "INVALID" but we may want to investigate what handling is possible first. later Michael, ok, if you want to support this in some way (other than the developer deletes the workspace and checks out anew again) - fine with me. Read on. I've had some kind of cross-team responsibility. If someone deletes files or directories in our team CVS repository from under any other person's workspace, I will want to find out who's done it, and I want to talk to that person. The general idea is that either the person didn't know what they were doing, or worse. There's little time to loose. The first thing I'll do is shut down the CVS server. It may still be possible to dig out last night's CVS repository backup and play back what's lost, without too much harm. However, if I let this continue unchecked, serious chaos may be on it's way. As I have CVS responsibility, I'll likely be the person that'll be cleaning up the mess. That said: If you as toolsmith want to do something sensible, please go ahead and do it. Only, what could that be? Most importantly from my point of view: People like myself want to be *informed* about the desease Eclipse tries to cure. I want a loud and clear message. Make it a bit dreadful. (If we're talking serious development, it is.) If the message scares the average coworker into asking their local CVS guru (me), just the better. The earlier I hear something's wrong, the earlier I can react. If your support is smooth as baby skin, you don't help me fixing the underlying problem. On a technical side, what can you do? Actually, there *is* a way to fix the whole thing from the workspace's point of view. Reserved for Grand CVS Magicians :-), if you will. Iterate through those CVS subdirectories of the workspace and remove, from the files ".Entries", the lines mentioning the files resp. directories that are gone. Well, to tell you the truth: I never said I'm a Grand CVS Magician myself. So I'm not absolutely sure about that recipe. I *think* what I've mentioned is all that's required. I *know* this is all that's required in common circumstances, as I have used this recipe before, but rarely. To make sure about the odd case, read Cederquist and, if all else fails, the CVS sources. After deleting those lines from ".Entries", the state is as if those old files and directories had been added locally by the user. Theoretically, the user could now choose to re-insert them to CVS. Please, DO NOT support any such thing. If any user does re-insert from the workspace, you (or, to be precise, I) have real chaos knocking hartely on your (my) door. Just consider another user, who now tries to update also. His workspace knows about high version numbers (let alone branch numbers) that don't exist any more, as suddenly everything is back to inital version. Now, what? What's really needed for resurrection is last night's CVS repository backup. And then you hold your breath, hoping nobody checked in any changes, after that backup has been taken... That's why personally, I would shut down that CVS pserver really quick, first thing, *before* asking further questions. All that said, I think a tool could try to support, in the situation we started with, firstly, "inform your local CVS gurus and have them investigate", and secondly, either "amnesia", or "wait, do nothing, until those files reappear from the backup". The catchup: The choice listed under "secondly" should probably be made consistently, across the entire development team. Again, if you ask me: Give it a hefty exception that propagates right up to the eyes of the user, and, other than that, leave it alone. Andreas, Thanks a lot for your input. It helps us a lot when those who have experience with CVS lend us their insight. I hadn't considered all the implications of handling remote folder deletions. This information will definitely help us when we investigate how to best handle this. >>I'm a Eclipse user, not a member of your team, but I've also been a CVS admin
>>for some time and so I take the liberty to comment on this one.
We appreciate feedback, good ideas, and technical insight from the community.
Thanks for the taking the time!
Action: - Should warn users when managed folders they have locally disappear from the server so they can take appropriate action (i.e find out where they went). - Shold also let the user know that their only course of action is to check the project out from scratch > Shold also let the user know that their only course of action is to check the
> project out from scratch
Yes, but...
doing so, a user may swiftly destroy the last chance for her company
to recover at least a recent snapshot of all that precious material
that was still sitting on her hard disk, but was accidently deleted
from the CVS server by a fumbling CVS maintainer (who doesn't know
to back up his repository regularily, either).
My suggestion follows:
You have some files or directories on your hard disk
that once seem to have existed in the central CVS repository,
but have disappeared from the repository.
THIS INDICATES SOMETHING IS PROBABLY WRONG WITH THE CVS SERVER.
Normaly, files do not disappear, with no history left,
from a CVS repository. No regular CVS operations ever do this.
CVS simply does not work this way.
However, not all is lost: There still is some version
of those lost files in your workspace.
For this and other reasons, you are strongly advised
to back up your workspace immediately.
Close down Eclipse and do it.
Next, you should inqurire about the repository state.
If, e.g., the repository will be restored using a backup of the CVS server,
it is best to not interact with the repository at all before restore procedures
have been completed.
If you're sure all is well with the repository, or as well as it will get,
and you want to restart working with it, you will probably have to delete
affected projects from your workspace and check them out from the repository
anew.
After that, you may want to use your workspace backup
to import back in any of your own work.
The above message sounds reasonable given the severity of the problem. Since it's too long for an error dialog, we'll have to come up with an alternate way to display it. Perhaps a dialog that has an error message like "Project on the server has been corrupted due to a folder deletion. Please contact your CVS administrator" and a Details button that will display the full explanation. This bug has not been touched in 2 years. Closing as WONTFIX. If you feel this bug is important, feel free to reopen it. |