This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If two developers make use of different code-formatting standards and both work on the same piece of code, the commited code becomes very difficult to CVS | DIFF (because each developer will tend to auto-format the code to his liking before recommiting it) This idea has been proposed before, albeit informally. JavaCVS should have an option to seamlessly code-format source code before commit it to the server. This way, regardless of the authors code formating conventions, CVS | DIFF will show useful results. Related enhancements: - Seamless code-format upon checkout, diff and all other code-viewing methods So you'd have to implement two-way seamless code- formating.. A group of developers would agree on a CVS- server code-format, while each developer would make use of his own private code-formatting conventions locally.. Running CVS | DIFF, CVS | Checkout would seamlessly convert the incoming code to the local user's private convention while commiting the code would convert it back to the global format. Off the top of my head, I feel this feature would be rather simple to implement (since the functionality already exists in other components). Comments? Ideas?
yup, agree it's quite a nifty feature, however it's mainly server side issue. check the CVSROOT/*info files, some of them let you access the to-bo-commited files, that's where you can do the server side formatting. that way all the commits in the repository will have the same formatting. So easy diffs between committed revisions. however the problem still persists for diffs with locally modified files (with other then server-like formatting). Dunno how to solve it other then attach a formatting engine to the diff command and let the engine pre-format everything that is sent to server during diff command.
If you preformat all code before commits, diff, and other other commands: 1) I won't have to change anything in my CVS server (personally I have no idea how to configure server-side formatting as you suggested) 2) CVS | DIFF will function as suggested So why not tack on a formatting engine in between all communication from/to CVS server - CVS client? Just be sure that you're dealing with source code you can format like *.java (i.e. ignore binary files)
I agree as well, that this would be a valuable enhancement. It would be nice to have this for all VCS integration, not just JavaCVS. I'm not sure, whether the code-formatter is going to be available for other modules (currently it's a part of editor module I believe). The problem of usage of different formatting by different developers was already discussed some time ago, but without a decission AFAIK. The idea was, that the code would be stored in some "unformatted" shape with all redundant whitespaces removed and formatted just for the editing. The problem is, that it will be unreadable in other editors (e.g. vi). I'm adding Mila on cc to ask whether there is a way to reuse the code formatter and whether there is some preferred solution to this problem?
Why is there is a need to store the code in an "unformatted" state? Why not simply store it in the author's private formatting style locally?
Well, the idea about the storage of "unformatted" code was just one idea I've heard and it was not about version control system, but generally about exchange of sources among developers. I don't think this is the way to go here, because the code would be unreadable for users of other IDEs. So yes, I agree, that the source stored locally should be formatted by the author's private formatting style and the version, that is send to the server reformatted by the shared formatting style.
I think that this could also be solved by something called view-based formatting that we would like to support in the editor (but please do not ask me about completion date of that). In essence you view the contents of the file in the editor with a different formatting (user formatting) than the one with which the file is actually being stored (the shared formatting).
The view approach might work as well, however I believe it would take much longer to design, implement and would have little or not extra benefits above and beyond the original idea to format all source code from/to CVS server and client. The view approach seems to suggest a constant layer of translation between the user-view of the file and the actual form used to store it to disk. This seems to suggest a lot of overhead. The original approach (abeit simplistic) only code-formats when necessary (when communicating with the CVS server). Am I missing something? Feedback is welcome..
Nice, implementable, but low priority really.
Changed component because this isn't CVS-specific.