Re: [platform-vcm-dev] New Feature - Run code cleanup on commit

["Rolf Wilms" <rolf_wilms@xxxxxxxxxxx>]

If consistent formatting cannot be guaranteed, including those
forgetting/refusing to format, a formatting prior to comparison would be
useful. I have had occasions where I wished it was that way.

On the other hand, the 'right' way of formatting is a personal preference,
especially when browsing foreign code, which some people do most of the
time. We had the discussion on how to format the 'right' way back in the
VisualAge Smalltalk days. Changing the method source editor to do a
formatting based on the personal preferences prior to displaying the source
ended these discussions (and just took two hours or so).

Prohibiting the use of 'format' by developers is too restrictive in my
opinion. Often you need to use 'format' to regain some structure in the code
you've just written.

Deploying a script on the server that formats the code using an external
formatter with some 'standard' formatting settings before actually comitting
is a good thing anyway. Ideally, this would cause fewer revisions (when
nothing has changed but formatting), use less space in the repository (only
real changes in the revision differences) and be beneficial to external
tools using the repository (i.e. CVS command line diff).

Regards,
            Rolf

----- Original Message -----
From: "Kevin McGuire" <Kevin_McGuire@xxxxxxx>
To: <platform-vcm-dev@xxxxxxxxxxx>
Sent: Tuesday, December 03, 2002 11:28 PM
Subject: Re: [platform-vcm-dev] New Feature - Run code cleanup on commit



Its an interesting idea and I appreciate the problem:  personally, I prefer
that people on the team don't use autoformatting (or if they do, that they
use the same styles/rules) because one small change and a reformat makes
compares very hard.

I will admit though that I am not keen on the idea of file content being
modified during the act of committing -- I think its better that a person
can see exactly what they are putting in the repo (and what they just
tested against).

Also, I'm not sure how compares work, since what people have locally in
their workspace won't match this formatting structure (if they did, then
you wouldn't need to do this on commit).  For example,

- I modify a java file according to my personal formatting preference
- I commit the file.  During the commit, it gets reformatted according to
the coding standards
- I then compare my file against the current one in the repo (that I just
committed) -- they will look different.

An alternative approach might be to format the text in the compare view
using your local formatting.  This way, the form of the stuff in the repo
doesn't really matter.  However, I believe formatting requires access to
the parse tree, which you can only get for methods that are in the
workspace, so the remote java file can never be reformatted on the fly.

Maybe a more achievable approach would be to allow the settings for
formatting, organizing imports, etc.,  be exportable and readable from a
separate "Team settings" file that everyone on the team can share.  With
one setting you point to this file (which could for example be on a network
drive) and everyone uses the same settings.  This would be a JDT
discussion.

Kevin






                      "Paul Austin"
                      <paustin@xxxxxxxxxxxxx>         To:
<platform-vcm-dev@xxxxxxxxxxx>
                      Sent by:                        cc:
                      platform-vcm-dev-admin@         Subject:
[platform-vcm-dev] New Feature - Run code cleanup on commit
                      eclipse.org


                      12/03/2002 04:54 PM
                      Please respond to
                      platform-vcm-dev





Here is a suggestion for a nice to have feature in the VCM module.

Typically projects will have coding standards around formatting of code,
imports etc. Developers however have their own preferred standards and will
do whatever they want.

What would be useful is that on a project by project basis you could define
a cleanup function that would be performed against files when they are
committed (and when doing a diff) to CVS (or other VCM). Then the functions
like code formatting and organising imports is kept consistent across the
whole project. The other nice thing about this normalization of code is
that
when you do a diff it will show a diff more based on the structure rather
than white space.

For the implementation I would recommend it be set up so that you can run
different tasks based on the file type, the types I would like to see would
be for java and xml files.

Any thoughts comments greatly appreciated,
Paul

Paul Austin
Galdos Systems Inc.?
paustin@xxxxxxxxxxxxx
Tel: +1 (604) 484-2761
Fax: +1 (604) 484-2755
http://www.galdosinc.com/

Privileged or confidential information may be contained in this message. If
this message was not intended for you, destroy it and notify us
immediately.
Opinions, conclusions, recommendations, and other information presented in
this message are not given or necessarily endorsed by my employer or firm.


_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev




_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev