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

[Daniel Carosone]

On Wed, Nov 29, 2006 at 09:16:10PM -0000, Boris wrote:
> I'm looking for a new revision control system and I'm very impressed from
> monotone so far. I read the documentation and understand how the development
> process looks like. I've some questions though:
> 
> After synchronizing how do I see what changes came in? I can do a 'mtn
> update' but then 'mtn diff' doesn't show me anything. Is there a way to see
> what another developer actually changed (the one my database was
> synchronized with) before or after I update my workspace?

You can use: 

 log {--diffs} --next n
 diff -r h:  

The latter will show you the inverse diffs that would take the newly
arrived head back to your current workspace contents..  we still lack
a simple magic selector for the base or current workspace revision
that would allow you to easily do something like:
 diff -r .: -r h:

It also assumes that there's a single new head; if there are multiple
you'll need to use more detailed selectors, like h:/a:fred and
h:/a:nancy

At that point, and in general, it's often nicer to look at the
revision graph forward from here with a tool like monotone-viz.  If
you fire that up in a workspace, it will start with the current base
revision selected, and you can see the shape of changes below here and
get diffs of each revision or between pairs of revisions easily.

It's also worth remembering at this point that you should always
commit before update; that way you can always bring your workspace
back to exactly how it is now if something goes awry either with the
update or the new code it brings in.

> How should software development in a team be organized ideally? Shall I use
> several branches?

It depends entirely on the team and the software and your preferences.
About the strongest recommendation I can make without further
knowledge is that you shouldn't be frightened of using branches to
help organise your work.  The way you organise your work is driven by
you, not by the tool, and monotone's branches give you lots of scope
for choices that might have been difficult with other (especially
older) tools.

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

pgpOZR8lq2Ros.pgp
Description: PGP signature