monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] 0.48 rants


From: Markus Wanner
Subject: Re: [Monotone-devel] 0.48 rants
Date: Mon, 19 Jul 2010 08:49:53 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5

Hi,

On 07/19/2010 06:54 AM, Derek Scherger wrote:
> Early on, uncommitted revisions were displayed with "(uncommitted)" on
> the Revision: line. This got lost somewhere along the way.

Fair enough.

> The case of a workspace with no changes is definitely bad right now. The
> workspace revision is shown as the Parent: and a new Revision: id is
> generated. At the very least in this case Revision: should probably be
> the revision of the workspace.

I'm objecting to the concept of a workspace having a revision id,
because I'm still lacking the use case for such a revid.

What you call the 'parent revision id' certainly is the more interesting
and a much more useful information than a 'revision id if committed as
is right now'. The former actually exists in the database and can be
looked up and queried different ways, the later doesn't.

> We could also display things printed right to left or upside down to
> achieve the same thing. I don't think that would be very good though,
> it's just another random format of the same information.  When status
> says "no changes" at the bottom the revision id should certainly be the
> id of the workspace which is not the case at the moment.

Based on the thinking that it should show information as if the
workspace is committed, it should probably rather show a warning that
the current workspace cannot be committed as is.

Otherwise you could argue, that it's not possible to commit a new
revision without any changes and get the same revid. (To get the same
look as 'mtn log').

> Recall the "oops I forgot to specify a new --branch option" case which
> is what got all of this started or are you specifically talking about
> the status output?

I've been specifically talking about 'mtn status', where I think it's
utterly misguided to try to mimic the format of a committed revision. It
simply is not a committed revision, it's a workspace. And my need for
information about that differs quite a bit from the one for committed
revisions.

I agree that 'mtn status' should still show the branch name that one
works on (and would commit to). I also agree that it's a good thing to
show both branch names, in case the parent differs from what you'd
commit to - both might be of interest. (And note that this requirement
already is different from the 'mtn log' format of showing things).

I could see use for being able to edit the branch name as part of the
commit message editing step. However, I'd expect that to be used rarely,
so it should not hinder you from typing the commit message starting on
line 1.

Regards

Markus



reply via email to

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