monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] closed branches (was cvs_import)


From: Daniel Carosone
Subject: [Monotone-devel] closed branches (was cvs_import)
Date: Fri, 16 Dec 2005 12:15:47 +1100
User-agent: Mutt/1.4.2.1i

On Thu, Dec 15, 2005 at 03:53:10PM -0800, Nathaniel Smith wrote:

> I think they got finished and merged back in to trunk. 

Hm. How can we help a long-running project detect such closed
branches, because they will become numerous?

For purposes of discussion, a 'closed' branch might be defined as a
branch which:

 1) has a single head
 2) that head has a propagate child, not in the branch
 3) the child is in the same branch from which the branch was derived
    (ancestor of the first node in the branch)?

These conditions are probably be too strong, and include too many
assumptions about branch development practices and usage
possibilities.  So we weaken or filter them a little, especially the
"put back" assumption in #3, and perhaps impose another condition to
make up some of the difference:

 4a) has a special 'branch completed' cert on the child (propagate)
    node (or on the head? I think i prefer it on the "merge back"
    result as a better conceptual model).

 4b) has a special 'branch abandoned' cert on the head, for branches
    that are development dead ends?

Note that under any of these conditions, a branch can be re-opened
later if needed just by committing a new revision to it, so even the
cert metadata doesn't have to be "final" in any restrictive sense.
(no need to worry about cert revocation issues)

So, with a suitable definition of a 'closed' branch from something
resembling the above, how might we handle it?  A selection of rough
ideas:

 - filter 'ls branches', and/or provide --closed, --open, -all
   restriction-like options on them?  Add a column to the output with
   a 'branch state' value?

 - consider the branch to have no heads at all?

 - consider the branch to have heads (say, for diff -r h:foo), but
   warn/refuse an update to it unless an update --closed (or similar)
   option is given?

 - warn when committing/approving a rev that re-opens a closed branch
  (like we for commits that create divergence)?

--
Dan.

Attachment: pgpnFddDpk6Hj.pgp
Description: PGP signature


reply via email to

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