Community
Participate
Working Groups
If you pick a revision from the History editor and pick "Add to workspace", the contents get loaded but the revision ID isn't updated. Its not just that the decorators aren't updated - I checked the Entries file and its incorrect.
There are two cases to consider here: 1) The user wants to load a previous revision of a file so they can look at it, and 2) The user wants to revert to the contents of a previous revision for the purpose of backing out the changes made since then. For case 1) , the user can view the contents from the resource history or the compare viewer. Therefore, it was thought that adding the resource to the workspace would be to support case 2). If the revision of the file were changed, the resource could not be committed back to the repository because of how the CVS update/commit work. Therefore, it was not changed. "Add to workspace" is a poor name for the action. Perhaps "Revert Workspace to Contents" or something else that conveys the intent would be better. If the ability to perform 1) above is desired, a second menu option could be added (such as "Revert Workspace to Revision"). The second operation would update the revision and prevent the contents from being committed.
I don't think "Revert" is a good choice. It implies that you're going back to something you had before, which is not necessarily the case. In fact, you could be going to something new that you've never loaded before.
I agree that "revert" may not be the best wording since the user may be bringing in a revision from another branch. In addition, there is a third case in which the "Add to workspace" is being used to load the latest revision from a repository while ignoring any local changes, in which case, you would want to update the revision number.
Discussion from newsgroup: Basically without the additional option to retreive the sitcky revision of a file you can't baseline mixed revision lineups. >If I replace a file in the workbench with an older revision, then the >revision info in the package-view and in the navigator is wrong. >There is still the revision of the newest version of the file displayed. >The ResourceHistory-view also displays the wrong revision. I think there is an existing PR for this, what is really missing is the option to either (1) replace workbench copy with contents or (2) replace workbench copy with revision (sicky tag the file). > 3) "Tag as Version" doesn't exactly do what it schould do! > If I use this function on a project in which older revisions of files > are in the workbench, then the newest files in the repository are > versioned. This behaviour corresponds to the rtag function in CVS not > to the tag. Thus the function in Eclpise should be named "Rtag as > Version". > The better solution would be to improve the function, so that we can > version > a project containing older revisions of a file. I think this is > absolutely > necessary. I think the "tag as version" works as expected, it tags the base revisions. But the problem really is that, as described above, you can't replace a workbench file revision with another revision and make it sticky. As a side effect, you can't make a tag with a mix of file revisions. I think by addressing the replace issue this would solve your problem.
*** Bug 6739 has been marked as a duplicate of this bug. ***
*** Bug 5937 has been marked as a duplicate of this bug. ***
*** Bug 13898 has been marked as a duplicate of this bug. ***
*** Bug 11615 has been marked as a duplicate of this bug. ***
Fixed. This PR addressed our inclination to not support mixed tags and sticky tags until now. I've basically enable most of the workflows, so beware that it is best if you understand CVS well before playing with mixed tag projects. If all you wanted was to revert a container to a previous version, compare with the version and user the compare editor to merge the changes into the workspace. To revert a file use 'get contents' from history view. - merge allowed on multiple selection, merge results show in same merge editor - merge allowed on all resource types - branching allowed on all resource types - replace with allowed on all resource types with multiple selection - warning dialog added when ever a user creates a project with mixed tags. It warns about the implied CVS behavior. Can be turned off. - tags only shown if different than parent tag (reduces tag clutter and makes it more obvious when a tag is different) - get revision for files allowed from history/replace/compare dialogs, to revert from a sticky revision use replace with tag and select the branch you are working on - CVS text decorations consolidated and as a result the text decorations in the sync view will follow the users preferences (except for the dirty flag which is not shown in the sync view)
