monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: current multiple heads (was Re: write access to


From: Derek Scherger
Subject: Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server)
Date: Thu, 29 Apr 2004 21:08:07 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040225

graydon hoare wrote:

 - rework the concept of disapproval to "do something else". for
   example, when dealing with persistent attributes of files we found
   that a versionned .mt-attrs file made more sense than trying to
   calculate cascading sets of file certificates. maybe a file called
   .mt-disapproved which holds the set of "live" disapprovals in a
   version. then the command "disapprove A B" makes a new edge A->K
   which contains nothing more than an addition of "A B" to the
   .mt-disapproved file. this would then cause future mergers of your
   branch to carry this disapproval forwards, and give a means for
   users to mark a disapproval as "fixed" (by removing the entry).

Most of this seems to be flying over my head as I'm not very familiar with the theories of operation you have developed for monotone over the past year or so. However, the above does make me think of something else that I've been wondering about.

I've been wondering how one might achieve a "floating" branch in a clean and easy way. What I mean by floating is that any files that have been changed on the branch would supercede their ancestors, which is essentially how things work now. Changes that are made on some other branch (like the trunk in cvs terms) where the floating branch is "rooted" would appear on (or be carried forward to) the floating branch "automatically". Maybe another way to describe this is that unless a file is changed on the branch I don't really want it to be branched.

Where I'm going with this is ... the current branch certs get created (as I understand it) because the branch is named in MT/options and every change in a working copy gets a cert with this branch name. If there was another type of cert that, once present on some version, would be carried forward to all derived versions until something else (another cert or cert removal?) stops it, a floating branch would seem possible. It also seems that a disapproval might be described with this type of "carry me forward" cert.

Sorry if this is a bit long-winded or if I've completely missed the point.

Cheers,
Derek




reply via email to

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