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.
pgpiY36RvSj8n.pgp
Description: PGP signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel