Community
Participate
Working Groups
We've been recently moved from a pure CVS command line usage to Eclipse with integrated CVS support. We normally creates a lot of patches and we code review every single patch we produce before committing the changes, therefore we always use the -w (ignore whitespace) flag on CVS command line in order to produce a more readable patch file to code review. It will be great if you can add a tick box on the Team->CVS preferences in order to enable/disable this flag.
Re-assigning to Platform -M.
(In reply to comment #0) > It will be great if you can add a tick box on the Team->CVS preferences in order > to enable/disable this flag. There is one in preferences General>Compare/Patch tab. Is it what you are looking for?
No, that one is just used when comparing files within Eclipse framework, what we are normally doing is to make the patch file using something like this: cvs diff -U10 -w -N > filename.patch then we attach the resulting patch file to the bug in Bugzilla ready for code review; this way another team of people will be able to look at the patch file directly within Bugzilla using the built in diff viewer. What we need is the ability to generate patch file with the whitespace (-w) already being removed by CVS diff command, also to be absolutely perfect the ability to specify the number of context lines (-U10).
This could be done either by adding two preferences (one for context lines and one for ignoring whitespaces) for CVS or by allowing to pass arbitrary parameters to the server. The latter option however introduces the possibility of passing parameters that would cause trouble on the Eclipse side. As we don't plan to address the issue in the 3.6 cycle I'm lowering the priority and setting "helpwanted" on the bug.
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.
