Re: `cvs add -m' in server mode
"Mark D. Baushke" <[email protected]>
| Newsgroups | gmane.comp.version-control.cvs.bugs |
|---|---|
| Message-ID | <[email protected]> |
Hi Derek, I like the idea of a general Create-Admin-File Clear-Admin-File protocol addition better. If we ever consider additions to preseve not just permissions on the file, but access control lists (ACLs) that are used in some filesystem security models it could provide a better structured container for such a feature. -- Mark Derek Robert Price <[email protected]> writes: > 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_ > >