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
Received on Thu Aug 19 03:00:47 2004