Bug 122122

Description nikolaus heger 2005-12-27 03:43:44 EST

[I know there's another bug with the same title which has been closed - however, that bug report (230) mixes several issues that have no relevance here so I don't want to reopen it.]

Problem: Often times, I want to back out of a change - revert to whatever version of a file I checked out from CVS. There is no quick way to do this: I either replace with latest CVS version, or manually pick the version number (which I memorize beforehand) from the history, or I know exactly when I had this version and replace with local history. All these features are useful on the odd occasion. But I want a simple revert which clears the CVS state and reverts the file to the version I checked out.

Solution: Look at the SVN plugin. It has a simple menu entry "revert" that does exactly what I want. It saves a lot of time and trouble when I temporarily add code (debugging code) or when I just want to back out of a change. As it is now, whenever I so much as touch a file, it gets marked as dirty in the CVS team perspective and then I have to deal with it - even if the changes are minimal, or if I decided not to do it after all, doesn't matter, I have to resolve conflicts and enter a whole set of time consuming procedures just as if I had actually changed some code. I also needlessly pull the same information over the network that I already pulled...

I find I use the revert feature in SVN basically all the time. It would be highly appreciated and a definite productivity booster. Besides, it should be easy to implement, just keep around a copy of each file that gets checked out from CVS.

This feature absolutely needs to network communcations or "sticky" tags in CVS (horror of horrors). I just mention that because that was cited as one of the reasons not to do it in bug report 230. 

The SVN plugin does it exactly the right way. No network access makes it extremely fast, too. 

It's also very useful to see what you have changed - like when I work on a set of changes over several days, maybe with some debugging and associated debugging code thrown in, then I can see very quickly which files I changed and in what way, which I want to revert - I can do all that before starting the synchronize, all with the data available locally on the machine. Which saves me network access time and potential meaningless conflicts and lots of "override and update" operations. It's *very* useful.