On Sat, Aug 26, 2006 at 10:45:24PM -0400, Ethan Blanton wrote:
> I find that I very much like the idea of 'monotone split' (after all,
> who hasn't accidentally commited an unrelated change along with a
> coherent changeset at one time or another?), but I'm not sure what I
> would expect monotone t
Ethan Blanton wrote:
Now, the hard part here is providing a UI for this which doesn't
require the user to carry around a lot of baggage; for two or three
logical changes it's not hard, necessarily (something like 'mtn split
-r B', 'mtn split -r B --whatever B1', 'mtn split -r B --whatever B1
--wh
Daniel Carosone spake unto us the following wisdom:
> The 'split' command seems like an interesting idea; if I understand
> correctly, it would create lots of parallel BB1, BB2, BB3... revisions
> as children of A, in the above example. The problem I forsee with
> this is that it will create a lot
On Fri, Aug 25, 2006 at 09:27:21AM +1000, Daniel Carosone wrote:
> On Thu, Aug 24, 2006 at 01:22:28PM -0500, Chad Walstrom wrote:
> > According to Justin's comment, which I think is right on,
> > you need to back out the changes in B completely.
> >
> > mtn disapprove B
>
> Um, not what I
On Thu, Aug 24, 2006 at 01:22:28PM -0500, Chad Walstrom wrote:
> So, if I'm following this correctly and referencing the DaggyFixes
> page, what we have here is something like this:
>
> A--B--C
>
> Where A is the buggy revision, and B is the revision containing the 5
> bug fixes.
Chad Walstrom wrote:
I don't think this would be possible. By the time you are inside the
editor to record your comment, monotone has already selected the files
to commit in the new revision. The best you could do is abort the
commit by comparing the log template before and after. If ther
"Andy Jones" <[EMAIL PROTECTED]> wrote:
> Oooh! People who use "dissaprove"! Keep talking. Do you use
> "approve" too? For what?
DaggyFixes wiki page explains it best. Essentially, all approve does
is assign a branch certificate to a revision. If the revision has a
common ancestor in the ne
You're right - DaggyFixes covers all that. Sorry.
On 24/08/06, Chad Walstrom <[EMAIL PROTECTED]> wrote:
"Andy Jones" <[EMAIL PROTECTED]> wrote:
> Oooh! People who use "dissaprove"! Keep talking. Do you use
> "approve" too? For what?
DaggyFixes wiki page explains it best. Essentially, all
Rob Schoening wrote:
As an enhancement to that, it would be equally useful to be able to
have an option to automatically include the diffs in the editor so
it's even easier to a) write changeset comments and b) double-check
that something isn't being erroneously included when it should really
Hmm. That's kind of counterintuitive, isn't it? "approve" and
"dissaprove" aren't mutually exclusive.
On 24/08/06, Andy Jones <[EMAIL PROTECTED]> wrote:
Oooh! People who use "dissaprove"! Keep talking. Do you use
"approve" too? For what?
On 24/08/06, Chad Walstrom <[EMAIL PROTECTED]> wrot
Oooh! People who use "dissaprove"! Keep talking. Do you use
"approve" too? For what?
On 24/08/06, Chad Walstrom <[EMAIL PROTECTED]> wrote:
> mtn disapprove B
>
> This will "internally create a new revision with the reverse diff as a
> child of B". So we get,
^--- Should b
A suggestion to help prevent this from happening in the first place:
One feature that I've always wished for with CVS (and Monotone) is a slight bit more interactivity with the editor on commit.
Intuitively, I've always wanted to be able to exclude files from commit by simply deleting the app
"Rob Schoening" <[EMAIL PROTECTED]> wrote:
> Intuitively, I've always wanted to be able to exclude files from
> commit by simply deleting the appropriate CVS: or MTN: lines in the
> editor that correspond to the files that I want to exclude.
I don't think this would be possible. By the time you
> mtn disapprove B
>
> This will "internally create a new revision with the reverse diff as a
> child of B". So we get,
^--- Should be "A"
> A--B--C
> `--BR
--
Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/
ass
So, if I'm following this correctly and referencing the DaggyFixes
page, what we have here is something like this:
A--B--C
Where A is the buggy revision, and B is the revision containing the 5
bug fixes. According to Justin's comment, which I think is right on,
you need to back o
On 8/24/06, Justin Patrin <[EMAIL PROTECTED]> wrote:
My point was: How would monotone know how to do such a thing? All of
I was just thinking of the same type of interface as the merge
interface, ie. with external tools. I have no clue how to do it, but
I just think it is an important work flo
On 8/24/06, Hugo Cornelis <[EMAIL PROTECTED]> wrote:
On 8/24/06, Justin Patrin <[EMAIL PROTECTED]> wrote:
> Since each revision is one monolithic set of changes you would be
> better off checking in each of the things you want a s different
> revisionsas different revisions. You don't have to
On 8/24/06, Justin Patrin <[EMAIL PROTECTED]> wrote:
Since each revision is one monolithic set of changes you would be
better off checking in each of the things you want a s different
revisionsas different revisions. You don't have to check in your
entire workspace. You can use restrictions t
On 8/24/06, Hugo Cornelis <[EMAIL PROTECTED]> wrote:
I like the explanation about daggy fixes a lot
(http://venge.net/monotone/wiki/DaggyFixes). I think what is still
missing in the monotone command set is a command to split one
changeset in multiple changesets.
For example, if a changeset cont
I like the explanation about daggy fixes a lot
(http://venge.net/monotone/wiki/DaggyFixes). I think what is still
missing in the monotone command set is a command to split one
changeset in multiple changesets.
For example, if a changeset contains a bugfix and a new feature,
perhaps you only need
20 matches
Mail list logo
