Re: cvs commitinfo - remote access issues - enforced code beautification

['Thomas S. Urban']

On Thu, Mar 21, 2002 at 09:15:00 +0530, Shubhabrata Sengupta sent 3.1K bytes:
> I think that the server "writes back" the files to the client. Isn't
> this the way keywords are expanded on the client side once the checkin
> is through?

This is true.

Greg, I'm replying to your stuff here, since your message never appeared
on my server.

> Greg A. Woods apparently wrote:
>> Hmmm.... but that can happen only on the server.  If you modify a file
>> unbeknownst to the user doing a commit from a remote client then you've
>> suddenly changed what he or she is committing without necessarily
>> telling them.

My experience is that the client will get all my automated changes as
long as keyword expansion will be done on the file.  Looking at the
client/server debug output files, it appears that the entire file is
sent back to the client even though perhaps a diff would do.  This is
perhaps a bug in CVS that I am taking advantage of.  CVS changes pretty
slow, but if this ever does, I'll have to reevaluate what I'm doing.

<snip>

>> Commitinfo can be used to reject a commit, but it should not ever be
>> used to change a file, and especially not to then allow the changed file
>> to be committed.  Users change files and then commit their changes to a
>> change tracking tool.  The change tracking tool should not itself ever
>> make any changes.

Well, tht change tracking tool already makes changes (keyword expansion)
;).  I agree that having the tool make automated changes is not the best
idea in theory.  But I don't live in a perfect world, and what I'm
doing fixes problems I am unable to solve through policy or discipline; 
not once since I've used my automation has it  caused any problems.

As an example, Take one of my minor modifications I make to source
files: if a c++/c file doesn't have a newline before the EOF, I add one.
The only reason I have to do this is because the Visual Studio editor
doesn't think that these are required.  Working in a primarily Microsoft
Shop, getting all our developers to use a proper editor to fix this
before adding files is really not possible.  Before adding my
automation, I was constantly cleaning up other peoples code when I got
warnings/errors on certain unix compilers which are merely ANSI
compliant.

There are possible problems with what I'm doing:

It is possible that a change could be made and committed that resulted
in a NOP revision added to CVS.  I could check for this and abort the
commit from my script, but haven't found the need.  In practice, this
hasn't come up, and if it does, the negatives aren't too strong - slight
waste of space in the repository and some unnecessary compilation on the
clients side, perhaps.

If keyword expansion is not on, the client won't get the modifications
made on the server side.  Couple with our policy of using
keyword-containing headers in all our source files, this doesn't happen
much.  The only time it happens is when someone adds a file to the
repository without the header.  My automation inserts the header for
him.  This might result in the client being out of sync (not a problem,
it's just comments), and even possibly a conflict if the out-of-sync
client then tries to add his header.

I could probably alleviate this problem somewhat by only doing the
processing if keyword expansion is done (another easy thing to add to my
script), but it's never really come up.  This is just conjecture.
Furthemore, for all the rather minor changes I'm making, the out of sync
problem, event if it did occur, doesn't change the functionality of the
code in any way.

If these possible conflicts I've never seen were to occur, the nature of
the changes I'm making is such that resolving them would be trivially
easy.

I wouldn't recommend anyone do this type of code changing lightly. If
you do want to do it, take the time to do it right.  My processing is
hightly configurable.  You can turn it off or modify what actions are
taking for directories , entire treees, or files that match a pattern.
Clients can do this configuratio by checking in small config files in
the appropriate place in the tree.  If any change is made to a file on
the way to bing committed, the original is archived.  In all cases, the
client is notified of all changes done, and where the backup file can be
retreived, if it's needed.  It's never been needed.

<snip>
Scott

-- 
Sometimes the best medicine is to stop taking something.