Re: [Monotone-devel] Re: Using monotone in a team

[Oren Ben-Kiki]

On Sat, 2006-12-02 at 14:26 -0800, Nathaniel J. Smith wrote (by mistake,
directly to me instead of to the list):
> On Sat, Dec 02, 2006 at 09:43:18AM -0800, Oren Ben-Kiki wrote:
> > Sounds strange to me. I'd expect the trust policy and (all? some?) of
> > the hooks to be part of the data that monotone allows copying between
> > the databases.
> > 
> > This raises some issues with merging branches - you'd want to merge just
> > the code changes, and not necessarily the policy changes. Also some
> > hooks depend on the developer environment (e.g. the messy line-ending
> > issue), while others may need be shared by all developers (e.g., simple
> > pre-commit verifications). So it may be necessary to have that
> > distinction be explicit in the system somehow.
> > 
> > Tricky as this may be to get right, this is something you'd expect every
> > distributed version control system to address somehow...
> 
> It's extremely tricky, which is why AFAIK monotone is the only system
> that has even thought about addressing it :-).
> 
> But, this is basically the kind of functionality that is covered by
> the "versioned policy" or "community branch" or whatever work, that
> we've been brainstorming about off-and-on.  Creating a branch that can
> be used to hold communal metadata about trust policies, branch
> statuses, etc.  (You _can't_ just stick the current trust hooks into a
> branch; evaluating those hooks would involve executing arbitrary code
> downloaded over the internet!)
> 
> -- Nathaniel

I can see that one could associate a "meta-data" branch with a "data"
branch to allow separating the two issues. That's neat because you could
add a "meta-meta-data" branch if you wanted to etc. (who guards the
guardians? :-) But I also see how extremely tricky this would be to
define :-(

People also raised the issue of security. As long as hooks are only
executed in the workspace, and as long as people are free to
accept/reject versions they fetch from other servers, I don't see the
problem. You can review the policy/hook changes and simply choose not to
use them. Put another way - people can already cause you to run
"arbitrary code" by simply adding entries in the Makefile. Policy hooks
are no different.

Oren Ben-Kiki