Summary: | [CVS UI] Provide warning dialog when saving to tagged version | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Craig Setera <craigsfnet> |
Component: | Team | Assignee: | Platform-VCM-Inbox <platform-vcm-inbox> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | Keywords: | usability |
Version: | 2.0 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Craig Setera
2002-08-15 08:52:41 EDT
Agreed - this is right in line with discussions we've had! I believe there are additional bug reports open on this subject. When detecting that the user is saving overtop a sticky resource, we may even offer to replace the resource/project with HEAD or Branch, but this is pretty fancy. All this is of course based on the assumption that users don't normally modify a sticky resource, and thus doing so is likely not what they meant to do. Kevin. You are welcome to mark this as a dup if there is another bug out there. I had an exchange with James Moody on the newsgroup and he asked me to submit the feature request. In answer to you last statement, I think there are really only two reasons that you would alter a sticky resource: 1) You really want to make a code change, but didn't realize that you were dealing with a sticky resource. I would guess this is the majority case. 2) You want to make a temporary change to some code (for instance someone else's code) to see what it does. In this case, branching might make sense as you may want to run the change past the real "owner". (We still maintain that mindset from VAJ to an extent) I look forward to hearing what you guys do with this one. Hi Craig, Thanks for your additional comments. They are in line with our discussion, which is reasuring for us (always good to make sure our model matches others!). The curiosity with CVS is that you can branch after doing local work. Our feeling, wrt. your second point, is that encouraging them to branch earlier reinforces a clearer work practice. So when modifying a sticky resource the options could be: "Do you want to: a) Branch this resource/project b) Replace with Branch, then apply the changes if possible c) Discard the changes d) Just keep working." When I first read you response, I wasn't sure I agreed. After pondering for a day, I think you are correct. I believe that the problem is that many of us are not yet used to a full CVS model. For instance, I've used CVS for home projects for many years, but I've never had a need for anything other than HEAD. Up until now I've really never considered branches for anything other than a differentiation between the mainline development and maintenance development. I think the design you discuss is a good one. I also think it would be great if someone that understood this (you or someone in the community) could put together example scenarios for the tooling to document "best practice" and various situations. Thanks for the comments Craig. This area is always tricky for us because it equates to "Make CVS easier", which we try to do where possible but at the risk of upsetting seasoned CVS users who are used to working in a different way. The scenarios are an excellent idea. We started writing them on this very subject (as a former VAJ user, this sticky file business drives me crazy!). I will try to find them and perhaps publish them somewhere where people can add/comment. Prompting is not practical since the CVS plugin does not have a UI context in the delta processor that would detect the change. What is provided instead in the ability to Update to another branch or version while preserving any local changes. This allows changes made on a version to easily be moved to a branch or HEAD. |