Re: RSE's cvs import patch against the current CVS source

[Mark D. Baushke]

Julien Wajsberg <address@hidden> 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