Daniel Carrera writes: > mtn rebase <rev> OK, that's an improvement on my proposal.
> The command "db kill_rev_locally" is long so I don't like it. What > would be the consequences of a divergence? Is it ok if I simply run > "mtn rebase" and then go on merrily on my way making my other > branches? If so, then I would be entirely happy with rebase. After "mtn rebase p:", there are two ways you could create a divergence: $ mtn commit creates a second head in the same branch; later on, "mtn checkout", "mtn update" and other commands will complain that there are two heads and require you to select a head manually. You can resolve that either with "mtn merge", "mtn suspend" or "mtn disapprove"; it's up to you. This is sometimes called "light-weight" branching; it is appropriate for short-lived divergences that you intend to resolve at one point in the future. The second way is: $ mtn commit -b new_branch The divergence is then "permanent"; you now have two branches with one head each; monotone will not complain about that. You can still merge whenever you want with "mtn propagate". This is sometimes called "heavy-weight" branching and is for intentional divergences that you think should live for a while (e.g. stable/maintenance vs. unstable/development). Note that "heavy-weight" is not that heavy; the only difference is the value of the "branch" cert. So "heavy-weight" does not consume any additional space in the database compared to "light-weight"; but it does consume from the branch namespace. -- Ludovic Brenta. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
