Re: Automatic pretty-print

The thing i don't like about doing pretty-printing as a checkin hook is
that you then have not built and tested EXACTLY what is getting checked
in. Developers shouldn't be checking in code without building and testing
first, right? Make the pretty-printing part of the build process. Have a
'make pretty' target that finds all writable relevant files and
pretty-prints them, then does a make clean; make test to assure they're
good. Developers are then required procedurally to do a make pretty before
committing changes. That way, you don't require Subversion to do something
it doesn't and probably shouldn't, and you don't check in untested
changes. Peer pressure can enforce little things like that.

---
David Stagner
FedACH Distributed Development
Federal Reserve Bank of Minneapolis
david.stagner@mpls.frb.org
612-204-6786
Zeus Gómez Marmolejo <zeus22@casal.upc.es>
08/18/2004 07:57 PM
 
        To:     users@subversion.tigris.org
        cc:     Chris Beck <cbeck@gene.concordia.ca>
        Subject:        Re: Automatic pretty-print
No,
This is not my case. I don't want to impose my programming style because I
think is better. All programmers in the group have accepted this style 
simply
because they don't want to see another piece of code that is not formatted 
as
they will expect only because other person wrote it.
We all are agree with this style but I think is to painful to impose the
programmers to do the pretty-print in each commit. I think for me this 
tool
(Subversion) is very good but it's missing some functionality. The
restriction for the pre-commit hooks not to modify the data is too strict. 
I
think for future releases, subversion could accept the modifications in 
the
pre-commit hooks, syncronize the commiter with these changes and insert 
the
new revision in the database.
Maybe this reason for pretty-printing is too fool to consider but I can
imagine a situation where the repository must be a 'canonical copy' of the
data summitted. I cannot think why all commiters must execute the 
canonical
transformation and not doing in the server-side if it's much simpler.
Zeus.
PS. I was thinking that maybe it was possible to do so but what you are
suggesting me that this is not possible. :(
Quoting Chris Beck <cbeck@gene.concordia.ca>:
> Perhaps what you can do is run it through pretty-print and if there 
> is a diff you can reject it with a warning?
>
>
> It is whispered that m christensen was heard, on or about 08/18/04 
> 14:49 to say:
>> Don't do this. it's a bad idea for several reasons.
>>
>> The Fact is you are mucking with someone elses code, even if you are 
>> the admin and
>> (think you)/(actually do know) better.
>>
>> The fact is pretty print or lint type programs can and do corrupt 
>> code or make non-standard but
>> more readable format changes that make a mess of code sometimes.
>>
>> Realize that it is 'you' in this case changing code, supposedly 
>> benign or not.
>>
>> Admit YOU are changing code and follow the same rules I presume you 
>> expect all developers
>> to follow.
>> Build your own working copy, pretty-fy it and update the repository 
>> with appropriate log entries
>> to document what you did and why. That way when something breaks you 
>> can identify why it happened.
>>
>> Sloppy and lazy work is demonstrated by lousy formatting, but this 
>> is hardly the only manifestation.
>> Formatting is easy to fix with the tools you mention but bad code in 
>> general is not.
>> The developers need to show a bit more effort at being professional. 
>> Even if it's just  formatting the code
>> before check-in or using a decent editor that can do it for them. If 
>> they refuse to do that it undoubtedly means
>> the code logic and testing is equally poor.
>>
>> Make them do their job right, IMHO.
>>
>>
>> Zeus Gómez Marmolejo wrote:
>>
>>> Hi all,
>>>
>>> I'm using subversion since no much time and I think it's great, 
>>> much more than
>>> cvs.
>>>
>>> I would like to ask one question. I want all the source .c files in my
>>> repository to be well pretty-printed, all conforming a common C 
programming
>>> style. But the problem is that the programmers don't do the job well, 
they
>>> forget to follow the rules and so...
>>>
>>> The ideal think could be at the pre-commit hook execute the pretty 
>>> printer for
>>> all the .c source files so that in the repository the files all are 
well
>>> stored. Also it would be desirable to check C syntax so all files 
>>> that are in
>>> the repository complile all. But I've seen the comments on the 
pre-commit
>>> template hook and explicitly reports that the script must not change 
the
>>> transaction. So is there a way to transform (pretty-print) the source 
files
>>> before committing them?
>>>
>>> If this is not possible, it will be very nice to add it as a new 
>>> feature :D,
>>>
>>> Regards,
>>>
>>> Zeus.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org