Re: `cvs add -m' in server mode

Derek Robert Price wrote:

> Local clients would (ab)use the timestamp field as well, if this works.
>
> I'm not sure what I did wrong, but a real timestamp got into the 
> ts_conflict field on the client in my prototype.  On the other hand, 
> I'm half way there if I'm setting the field at all on the add -oh.  
> Hrm. Maybe not if the client is looking up the timestamp on the file 
> since the server's may have differed.  Well, it was worth a try.  I'll 
> let you know how it turns out.  :)


It turns out this doesn't work as well as I was hoping it might.  I 
misread the client side code - it is doing more interpretation than I 
thought, so I can't squeeze through the extra data in any of the entries 
fields in the clear.

I'm still thinking of fixing this, though it will now require client 
changes.

I'm contemplating either using an extra field at the end of individual 
entries, as well as a change so that future clients will preserve 
entries fields which they don't understand (possibly enabling 
server-side fixes like I was attempting), or creating more generic 
Create-Admin-File & Clear-Admin-File protocol transactions which write 
or delete arbitrary files in the CVS dir, as well as the machinery to 
send any files in the CVS dir which the client doesn't recognize back to 
the server, which should also enable future server side fixes in similar 
situations.

Both solutions seem approximately equally extensible, though in the 
first case, entries lines might start looking pretty messy, for instance 
with long, multi-line descriptions.  Of course, the entries solution 
should be significantly less work, a strong point in its favor.

Anyone have any advice, preferences, or opinions?

Derek

-- 
                *8^)

Email: [email protected]

Get CVS support at <http://ximbiot.com>!
-- 
I will not pledge allegiance to Bart.
I will not pledge allegiance to Bart.
I will not pledge allegiance to Bart...

          - Bart Simpson on chalkboard, _The Simpsons_