Community
Participate
Working Groups
When tagging files via the repository view, files from multiple repositories, projects, and tags can be selected. In order to allow this behavior, the TagInRepositoryOperation loops over all resources and tags them individually. This works correctly, but generates considerably more CVS traffic than is necessary. As a result of the loop, every resource results in a separate hit to the associated CVS servers. Because of these separate hits, multiple taginfo events are also generated on the server. Software that uses taginfo events to fire programs or log information about CVS access end up handling multiple events. I my case, the CVS server ends up sending an email for each file tagged. TagInRepositoryOperation should be modified to batch CVS hits by repository and source tag. This would be sufficient separation to allow the current behavior of the repository view to work correctly, but would allow multiple tag operations against the same repository and tag to be sent to the server as a single operation. I have part of this work under way now, but would like comments.
Are you saying you ar working on a patch and want to know if the direction you are taking is correct? If so, the answer is a definite yes. The behavior you describe would be the most desirable. If you are working on this, feel free to ask questions either in this bug report or on the platform-cvs-dev mailing list.
You are correct, I am working on a patch because we have need of this behavior, and I'm glad to hear this is the correct direction. The only snag I've hit so far is that when rtagging a remote file based on a specific tag, Eclipse CVS is sending -r <revision> rather than -r <tag>, presumably to support tagging using so-called "date tags" which have no real analog within CVS. I believe in order for this batching to work, rtagging files under a specific named tag must be modified to -r <tag> instead. I think tagging this way would also qualify as a bug, given the following scenario: 1. User #1 refreshes their repository view and navigates to file myFile.java, revision 1.1, under tag "MYTAG" 2. User #2 commits myFile.java 1.2 and tags with "MYTAG" 3. User #1 attempts to tag the myFile in their view with "MYOTHERTAG"; however, their local view knows only about 1.1, and passes this in the "cvs rtag" command. The intention here is to tag the most current "MYTAG" revision, but instead the previous revision gets tagged. Using revision to tag files under a specific tag is also not really in line with how stock CVS would do it. If I wanted to tag the "MYTAG" version of a given file, I would specify -r MYTAG...not -r <revision> My patch currently is working correctly other than this little glitch, but it's a pretty significant glitch. Fixing it would modify the way Eclipse CVS rtags tagged files...any comment? Should this go under a new bug?
The problem is that if a user selected 5 files in the repository view and chose to tag them, it is hard to say whether they are interested in tagging the latest on the branch or the exact revisions. If the tag is a version tag, there isn't really an issue since the revisions don't change so you could just use rtag with the common version tag as the base. However, for HEAD and branches there is no way to know what the users intent was. One possibility would be to prompt the user if they have selected files (on a branch or HEAD only) to ask them if they want to tag the specific revisions or the latest on the branch. It's not the greatest to have an extra prompt but a MessageDialogWithToggle would give the user the option to avoid it in the future. I think this issue needs to be addressed by this bug since it would be a change in behavior and also because, if the user chooses a file directly, they could reasonably expect that exact revision to be tagged.
So perhaps we're closer...am I hearing that you agree that rtagging files under a version tag could reasonably be assumed to mean the user wants to tag the revision associated with that tag (as opposed to a specific revision)? That's probably 50% of the battle right there. So we have the following: Tagging of files under a version tag should use -r <tag>. Tagging of files under a "date tag" should use -D <date> (not sure if it does this now or not). Tagging of files under a branch (HEAD or otherwise) is still questionable, and might need to be revision based AND -r <tag> based. That about the size of it?
That sounds about right to me.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
