monotone-devel
[Top][All Lists]
Advanced

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

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


From: Hugo Cornelis
Subject: Re: [Monotone-devel] Re: Using monotone in a team
Date: Sat, 2 Dec 2006 12:15:34 -0600

On 12/2/06, Oren Ben-Kiki <address@hidden> wrote:
On Sat, 2006-12-02 at 01:49 +0000, Boris wrote:
> Hugo Cornelis wrote:
> > Well, what I really want to do is have a mechanism that automatically
> > distributes the necessary hooks from one central point.  For sure the
> > members of the same team need the same trust policies, local
> > alterations not allowed.  So if you want to join the team, you first
> > have to synchronize the trust policies.  This does not preclude simple
> > cloning for private work.  Perhaps the right question is, does this
> > layer belong to monotone or not ?
>
> I guess it does not belong to monotone. As you even want to forbid
> developers to change trust policies I think a distributed revision control
> system is not what you want. What monotone does is copying data between
> databases. Once it is there revisions can be combined flexibly. And how they
> are combined depends on the local configuration (the hook functions). At
> least that's my understanding so far (as usual without any warranties ;).

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...


Lets talk about monotone proper (version control) and monotone add-ons
(trust-policies and others, essentially everything that is project
configuration for monotone proper).

The following was a result of a small brain storm.

Then, I guess, a checkout, can first trigger a hook, hard coded in
monotone proper that first obtains a monotone add-ons database,
perhaps after a round of pulling from other repositories to assemble a
right local database (so here is an assumption that the other
repositories are known somehow).  Second, lets assume that the add-ons
database contains various tags or branches, reflecting various
operating systems, line ending policies and project policies (so
assume that the tag names are known a priori, e.g. i386-linux-gnu).
Third, these branches are merged according to the local operating
system tag, line ending policy tag and project policy tag, as far as
allowed (a good config design can differentiate between local and
global settings, even after a merge).  Fourth, the project code is
checked out, and the local configuration is applied (running the Lua
hooks ao).  Fifth, the code is ready to be edited.

I am not sure if this all makes sense, it sounds difficult and
complicated at the same time to me.  I think it is best to separate
such issues from monotone proper, functionally and technically.


Hugo


--
                   Hugo Cornelis Ph.D.

                 Research Imaging Center
  University of Texas Health Science Center at San Antonio
                   7703 Floyd Curl Drive
                San Antonio, TX  78284-6240

                   Phone: 210 567 8112
                     Fax: 210 567 8152




reply via email to

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