[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: `cvs add -m' in server mode

From: Mark D. Baushke
Subject: Re: `cvs add -m' in server mode
Date: Wed, 30 Apr 2003 08:53:43 -0700

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 <derek@ximbiot.com> 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: derek@ximbiot.com
> 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_

reply via email to

[Prev in Thread] Current Thread [Next in Thread]