Community
Participate
Working Groups
Currently, there is no indication, if you have turned off CVS decorations, of what "version" of code you have in your workspace. It may be a branch, head or some tagged version. If a user inadvertantly makes a number of changes on a sticky tagged version and subsequently attempts to commit those changes, an error will occur. At that point, a number of steps involving branching and merging are necessary to get the changes committed onto the branch (most likely HEAD) that the user had originally intended them to be on. This is especially true of former VAJ programmers (like us) who are not yet used to CVS and all of the intricacies about how it works. It would be nice if on the first attempt to save a file in a tagged version, the workbench would warn the user that they are in a tagged version and will not be able to simply commit. This would help to lower the number of potential changes that might have to be merged and the steps necessary to do the branch/merge operation. Another potential implementation would be to show the warning dialog on every save, but allow the user a button to say "I know what I'm doing, please leave me alone". This *might* be better, if a user has loaded a version and attempted one change and then come back a week later and tries it again. Not sure how much hand-holding should be done though.
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.
