Bugzilla – Full Text Bug Listing
| Summary: | [Wizards] Tag after commit | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Marcelo Paternostro <marcelop> | ||||
| Component: | CVS | Assignee: | platform-cvs-inbox <platform-cvs-inbox> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | alex.blewitt, apratt, dominik.skorka, fromEclipseBugzilla, jptoomey, klomeli, nikolaymetchev, peter.dick, slavescu | ||||
| Version: | 3.0 | Keywords: | helpwanted | ||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Marcelo Paternostro
This bug has not been touched for 2 years. Closing as WONTFIX. Please reopen if you feel this is still an important issue. I would prefer to read a technical reason for this. I didn't know I was supposed to send "keep-alive" packages for my bugs ;-) Anyway, I think am fine with your decision - the process I use has changed a lot in 2 years and this is not a problem anymore. I do think it is a "nice to have" though. I agree that "keep-alives" shouldn't be necessary. The assignee could add something to solicit input (like has happened now) without closing the bug. Marcelo, I don't know why you say this isn't a problem any more. As far as I know the process for fixing bugs still includes tagging the checkin with the Bugzilla ID of the bug you fixed. As such, this enhancement is as valid as ever. Without this feature, I have to go RE-select all the files I checked in and use the "Tag" operation. This is error-prone, since the files I committed are no longer gathered in one place (e.g. in the Synchronization view). Here's what you have to do now: 1. Run "Synchronize" 2. Select files to commit from the resulting display. 3. Commit them, supplying a checkin comment for them all. 4. Notice the files disappeared from the Synchronize display. Curse. Go back to the Package explorer, try to remember all the files just committed, select them, choose Team > Tag. Forget one, go back and do it again. The feature proposed here would eliminate the aggrivation at step 4. (If you don't forget, you can do step 2.5: Navigate > Show In > Navigator. But I always forget.) Probably I should have said that the CVS/Bugzilla process I use has changed because I am not working on the same team I was when this bug was openned. As pointed out by Allan, this feature request would make the commit process much easier for some folks using Eclipse and CVS - and, again, would mimic the -r option which is something CVS users are used to have. I am reopening the bug. The reason for the "keep-alive" is that the number of bugs against Team and CVS has reached an unmanageable number. In essense, I am delegating the pruning process to the people who reported the bugs. Moving to LATER as we currently have no plan to address this issue. I'm quite interested in this enhancement as well. Is the issue one of resources or of merit? Put another way, if I went to the trouble (at some point in the future) to code it up and submit a patch, is it agreed that the enhancement is of enough general interest that it would be committed? I'm pretty under the gun on TPTP work at this point, but I wouldn't rule out spending the time to do this work in the future if I knew that would get the feature in. I don't think I would agree to a patch that simply did a tag after a commit. What I would agree to is a patch that introduced a post (and possible pre as well) commit callback that other plugins could plug into. Then any 3rd party could decide exactly what they wanted to happen before or after a commit. We had considered doing this but just don't have the manpower. If I still have to drop my own plugin into my dev environment (which changes at least as often as Eclipse milestone drivers, often more frequently), it is much less compelling. What I'd really like is for the Eclipse CVS support to provde the ci -r functionality that the commandline CVS client provides. I don't have the time to look at this right now, but if I found some time in the future, what about a patch including: 1) pre & post commit callback extension points. 2) a CVS preference that specifies the desire or lack thereof to support tag after commit. Default preference value of false. 3) additional code in the commit dialog that adds an addition field to specify the tag name if #2 is set to true, and an implementation of a post commit callback which is used when #2 is set to true to tag the commited versions with the specified tag name. Would this be agreeable? Sounds acceptable. Created attachment 20848 [details]
A mock-up of a proposed UI
Why have a preference to enable tag-after-commit? You can't use this feature without getting the text of the tag from the user anyway, so put the enabling checkbox in the "commit" dialog. I have attached a mocked-up image of the UI I have in mind. In the Commit dialog, there's a new section: a checkbox titled "Apply this version tag to the new version(s)" and a blank below it. If the checkbox is unchecked (the default), the blank is disabled and the behavior is as before. When it's checked and the blank is filled in, you get the -r behavior. There is a checkbox under the blank, "Move tag if it already exists," just like the current "Tag as version" dialog has. Finally, this bug still appears to be "resolved," not in any open state. I've reopened it. I suggested the preference because I think the thought is that this enhacement will not be of interest to a large percentage of users. I think there was concern about further cluttering up the commit dialog (note that in 3.1, there is already a karge new section below the commit description showing the change set.) By adding a preference, the defaul UX would not display this option at all. Of course, that means interested users would need to know ow to find it in teh preferences, but that's not a huge concern to me. Doh, I just lost my comment and I'm not going to retype it all. The short of it is that the tag input will ned to be on a separate page in the commit wizard because, in 3.1, the commit has a details under the comment that allows the user to preview the files that are about to be committed. I think this new page should come after the comment page since I suspect most users will not tag on every commit. If the page comes last, we do not need a preference to disable it since the user will just click Finish on the comment page. This new wizard page could have the ability to tag with a text label (cvs tag) or a common revision numbr (cvs commit -r). *** Bug 98218 has been marked as a duplicate of this bug. *** *** Bug 103683 has been marked as a duplicate of this bug. *** *** Bug 105890 has been marked as a duplicate of this bug. *** *** Bug 110929 has been marked as a duplicate of this bug. *** here is currently no plan to address this item. Patches will be accepted (as discussed in previous comments). Are there any plans to add this in the next version of eclipse? No, there are currently no plans to address this issue. (In reply to comment #20) > No, there are currently no plans to address this issue. I'm sorry to hear that -- I currently work for an organization that has some weird ideas about CVS (they never branch, only tag individual files with bug ids), so I could REALLY use this feature. It seems like it would be a really simple one to fix. I would happily volunteer to put it in! :-) - Tim Tim, you are free to go ahead and and work on this item. However, while I believe it would be fairly straight forward to modify the commit wizard to always (or even optionally as shown in the link in comment 7) do a tag after a commit, it would be much more work to generalize this to allow multiple post-commit processors. Having said that, if you want to tackle the problem in a manner specific to tagging after a commit, then be my guest. We would be happy to accept such a contribution. Please don't come up with something that "always" tags the file ;-) This has to be an optional step. Guys, how about adding a switch into "Team Synchronizing" perspective which would simply prevent disappearing of files after a commit? Or more general thought. As far as I understand, files disappear because the perspective is synchronized again automatically after i.e. commit operation. Let us introduce a switch for this - a manual/automatic synchronization. Obviously, those files would have to be marked somehow to allow a user to distinguish them from not-yet-committed items (different colour, font, name it...). "Team Synchronizing" is a right way of introducing changes into a repository, but as Allan pointed out in his comment #3 this becomes useless if users are forced to _remember_ the list of changed items... Dominik As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |