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

[Hugo Cornelis]

I did not see such a thing like 'certs' with other version control
systems (I could obviously be wrong on this), but, because certs allow
for many different types of user defined workflows, it is exactly the
reason why I started using monotone.

There is a learning curve involved when dealing with certs, because
they come in handy at different places, and, as it seems, sometimes
fit different functions.  For the moment the wiki comes through as a
bit 'theoretical'.  I think it might be useful if the wiki contains
more examples of how to setup things like the (almost hierarchical)
work-flows explained below.


Hugo


On 11/29/06, Daniel Carosone <address@hidden> wrote:
> > I ask as I might not want to accept every change a developer came up with.
>
> That's one thing that branches make easier to track.  If you're the
> reviewer for submissions from others, you might keep a 'blessed'
> branch, and approve (or propagate) revs onto that branch when they
> meet your criteria.  You should set your trust hooks such that branch
> certs for that branch from non-reviewers are ignored.
>
> Submitters could commit to a common submissions branch, or per-author
> or per-feature branches.  They could develop amongst themselves on
> their own branches for many revisions, and mark milestone revs they
> intend you to review for inclusion by putting them on an integration
> branch.
>
> Or you could work all in one branch, and have them indicate their
> intention that the rev should be integrated by simply committing, but
> not trusting their certs at first until you've reviewed the rev and
> added your own branch cert seconding the approval. Over time you might
> choose to trust the certs of others on their own merits.
>
> However you use branches, you can use other certs (like the testresult
> cert) as part of your criteria, either as a precondition for review or
> as an automated equivalent.
>
> I tend to be a fan of "more annotation helps" and recording even small
> steps in history, especially as revs can be in multiple branches each
> can have its own meaning without excluding others.
>
> > Currently I can only do a 'mtn update' and whatever was synchronized ends up
> > in my workspace. Do I miss anything? Or is this just the way monotone works?
>
> Update (and several other commands) use the trust evaluation hooks to
> decide which revisions to accept into the workspace.  You can choose
> how you set them, and you can choose (on that basis) how you mark
> incoming revisions as acceptable.
>
> Have a look at the TrustFoundations wiki page, and several others
> linked from there.
>
> --
> Dan.
--
                   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