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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
