Jim Blandy wrote:
> Given general-purpose properties, both historied and non-historied, I
> don't think the filesystem should require any special-purpose features
> to support reserved checkouts --- it can be implemented in the client.
Getting better all the time. I like that.
> I think the most interesting issues here are in the human interface
> side of things. I designed `cvs watch' and `cvs edit', and they suck
> rocks. Nobody can remember how you're supposed to do things. Perhaps
> someone on the list could describe a reserved checkout interface they
> enjoyed using...
If you put it /that/ way ... I don't enjoy using, I just get a kick
out of writing. :-)
Seriously, "cvs watch"'s main problem was/is that it wasn't a policy
set in the repository, but mostly a user-preference setting. Yes, things
have changed a bit now, what with CVSREAD, etc. You want (or rather,
/you/ don't want, but some people do :-) to make reservedness of co's
a property of the repository elements, or subtrees, or whatnot.
I like the way ClearCase does that: You have a policy, which you may
or may not be able to override; there's also a fallback mode available
-- check our unreserved if it's already reserved by someone else.
All of that gives you a lot of flexibility. Combined with a good
access permission scheme (e.g., /my/ checkouts are unreserved by
default, but /you/ will always have to ask nicely :-), it can be
a very powerful tool.
As for user interface thingies ... Off the top of my head I'd propose
something like this, given the following commands: get, update, commit
checkout, checkin:
get:
create working copy, making files writable or not depending
on each file's reserved-checkout policy;
update:
update the WC, with same behaviour WRT file flags;
commit:
commit changes in the usual way, /without/ changing
file flags or lock status;
checkout:
update, and for files with unreserved checkout policy,
lock it and make it writable; With appropriate permissions,
can override the file's checkout policy (with a flag) until
the next checkin;
checkin:
commit, and if it was locked, unlock it and set the file
flag according to the file's checkout policy (meaning that
it might become readonly, or it might not).
Note that when I say "file", I should in fact say "object version".
You might want to allow unreserved checkouts on files, for instance,
but require reserved checkouts for directories when adding new
objects.
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:12 2006