[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Using monotone in a team
From: |
Oren Ben-Kiki |
Subject: |
Re: [Monotone-devel] Re: Using monotone in a team |
Date: |
Wed, 06 Dec 2006 08:28:52 -0800 |
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
- [Monotone-devel] Re: Re: Re: Re: Re: Using monotone in a team, Boris, 2006/12/01
- Re: [Monotone-devel] Re: Re: Re: Re: Re: Using monotone in a team, Hugo Cornelis, 2006/12/01
- [Monotone-devel] Re: Re: Re: Re: Re: Re: Using monotone in a team, Boris, 2006/12/01
- Re: [Monotone-devel] Re: Re: Re: Re: Re: Re: Using monotone in a team, Hugo Cornelis, 2006/12/01
- [Monotone-devel] Re: Re: Re: Re: Re: Re: Re: Using monotone in a team, Boris, 2006/12/01
- [Monotone-devel] Re: Using monotone in a team, Oren Ben-Kiki, 2006/12/02
- Re: [Monotone-devel] Re: Using monotone in a team, Hugo Cornelis, 2006/12/02
- [Monotone-devel] Re: Using monotone in a team, Boris, 2006/12/02
- Re: [Monotone-devel] Re: Using monotone in a team, Brian May, 2006/12/02
- Message not available
- Re: [Monotone-devel] Re: Using monotone in a team,
Oren Ben-Kiki <=
- Re: [Monotone-devel] Re: Re: Re: Re: Re: Re: Using monotone in a team, Timothy Brownawell, 2006/12/02