Julien Wajsberg <[EMAIL PROTECTED]> writes: > > > How about modifying this ? > > > > I believe it would be a waste of time. There is still an 'enhancement' > > request http://ccvs.cvshome.org/issues/show_bug.cgi?id=27 to have the > > verifymsg processed only once rather than for each directory... > > > > Somewhere before the call to do_verify ? > > > > I'd suggest that this is not a useful distraction for RSE right now. > > If there is no advantage at doing that, surely it is a waste of time. > But if it adds coherence, why don't you want to add this feature in the > good way at the first time ?
In what way does it add coherence to modify the existing behavior and add a new feature at the same time? I suppose that making both changes at once may have some benefit, but the existing feature for RSE is apparently one that works and is stable. All we are asking for is some additional documentation and test cases rather than new development work. > Moreover, it could help (later) if you want to modify the code in > order not to show an editor if commitinfo is failing, for example > (just a thought). I suppose you may have a point. Right now the client/server protocol expects the log message to be transmitted over the wire at the same time that modified files are being copied to the server for consideration in the commit. So, the local 'editinfo' prompting for the log message occurs before any file is transmitted so that the log message along with all possibly modified files may be transmitted in one transaction to optimize keeping a remote link open for the shortest period of time possible. This has the side-effect folks doing on-demand dialup will pay the least amount of connect time for a single commit. It also means that the server keeps the remote snapshot of the user's changes for as small a period of time as possible. If the intent is to optimize minimum input for the user, it might make sense to be able to reject a commit without even getting around to prompting the user into reading the log message... however, some users take a long time to write interactive log messages and these users would be keeping the server diskspace and network connections open which will increase the load on the server during the time that the user is writing a log message using their local editor. If the 'normal' condition is to have a commit succeed, then the added load would seem to have no upside. If the 'normal' condition is to reject commits, then your proposal may have greater merit. I am just not certain how much the remote protocol would need to be extended to deal with the late transmission of the log message (I have not looked closely at that part of the protocol). I suspect that the current method makes more sense from a network bandwidth and server transient disk consumption point of view and any change is going to have to try to justify that extra load and possible connect-time expense. Enjoy! -- Mark _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs