[I know this isn't the DCMS list, but the descriptions of rationale may be
of use hear.]
> What I am getting at here is if you try work under a model
> where every commit is for a specific reason (ie. a feature
> or bugfix) then in theory the whole change is a logical
> set that shouldnt be divorced from each other.
Speaking for DCMS (another current CM effort), this is a policy issue. Prior
to the point where you are in the production maintenance cycle, you want to
be able to merge subsets. After that, you may wish to impose an all or
nothing policy.
The DCMS "solution" to this is to use scripting code that can embed such
policies. While the specific policies are ad hoc at the moment, our general
view is that the CM system should support well-defined triggers and a
built-in scripting language (i.e. not shell scripts -- multiplatform and
security issues here), and should NOT have random option flags in a config
flie somewhere. The former is potentially maintainable. The latter is less
so, and it has been my experience that in practice option flags are stored
in a single global file which makes them hard to set on a per-project basis
(e.g. .cvsrc in $HOME).
> #2 - Granularity of ACL's
>
> I understand that their are properties that can control
> access for files and directories. But what about
> branches, or tags???
Again speaking for DCMS, we're actually taking the view that there
*shouldn't* be access control on files or directories. We do it only on
branch and project (we may extend this to branch versions, but that creates
merge problems). If you have access to the branch you should have access to
the contents referenced by that branch.
The only access control that DCMS has on files/directories devolves from the
use of a cryptographic hash naming scheme for objects. If you know the
object name (e.g. by obtaining it from a configuration record in a branch)
you can get the object, but it is pragmatically impossible to guess the
object names. The net effect of this is that you can have private branches
and versions.
Note that files and directory objects in DCMS are immutable, so there is no
need to write protect them.
Some may object that fred could tell mary the name and then mary would have
access. In this case fred could also simply ship mary the object, so
protecting the name is not helpful.
shap
Received on Sat Oct 21 14:36:06 2006