Written in stone.

mpm backed out the change in 8a5d8fb59ed2, so I guess this is on hold until we
have to change the output of 'hg status' for another reason.

If Thomas is correct that this only went in in 0.9.3, then the answer
is: it wasn't quite implemented in the way that it should have been, it
is a bug, there is no compelling backward compatibility issue, hg is
still pre-R1 in any case, and it should be fixed. The fact that the
ill-selected behavior is documented does not alter the fact that it was
not the preferred implementation choice. The fact that seeing the
ill-selected behavior requires obscure options and arcana does not
excuse the ill-selected behavior.

My question is: given that the current behavior is very new and not
quite right, why are we arguing about a single character change that
will simplify a range of tools. I see us accepting behavioral fixes in
other areas all the time, any number of which might hypothetically break
scripts. Why so defensive about this one? Considered overall, the net
reduction of code in other tools will probably increase their stability,
and that will ultimately make everything work better.

Or conversely: why not equally conservative about all the other
behavioral changes if we are going to be conservative about this one? To
be honest, I might prefer greater conservatism all around, since the
number of instability reports I see in me inbox is disturbing from my
perspective as a user. I wonder if we shouldn't be in a complete feature
freeze and bug hunt -- but that's just me, and it isn't my decision to
make.

Matt: email is a terrible medium for this type of note, so I want to
say: I am not trying to be obnoxious here. I am trying to raise a
serious question about how HG should deal with balancing stability and
feature change at this point. I do think that we are not being
consistent in this case, and I think that inconsistency of this sort is
probably not a good thing, but my main point is to ask how the line
should be drawn at this point.

Jonathan

On Mon, 2007-12-31 at 16:11 +0000, Matt Mackall wrote:
> Matt Mackall <mpm@selenic.com> added the comment:
> 
> Why are we even still talking about this? We don't break backward-compatibility
> for wishes, period. There isn't even an argument that this is a bug. It's
> documented behavior ...

Why are we even still talking about this? We don't break backward-compatibility
for wishes, period. There isn't even an argument that this is a bug. It's
documented behavior and you have to actually read through the documentation (hg
help st) and use -C (gigantic hint) or -A to see the state.

If you've done all that and it still surprises you, there's not much we can do
for you. On the other hand, if you've done all that and coded it into your tool
which then breaks a year later, you'll rightly be pissed. 

Again, the output of hg status is intended to be both stable and parsable
precisely to be used by tools. It can't be changed without a very good reason.
This is categorically not such a reason. Please backout the change in crew.

ps: the 1.0 arguments aren't interesting, we've been promising backward
compatibility for ages.

The "C" flag is used since release 0.9.3, that is "only" one year ago, so not
even the version in Debian etch (0.9.1) knows about "C".

The number of bug reports doesn't reflect the number of people being bitten by
this. Most people would just think "oh, shit, Mercurial is different".

If we don't reuse the now free "C", external tools can easily be compatible with
both output. So the impact on external tool writers shouldn't be to high, not
even a hg version check is needed.

Eric S. Raymond wrote:
> Jonathan S. Shapiro <shap@eros-os.com>:
>> Concur. If we are going to do this at all, it should be done before hg
>> 1.0.0
> 
> And, on the flip side, I don't think it ought to be done after 1.0.0.

I'd somewhat like to see the change, too.  I use Mercurial, Subversion
and darcs every day, and git pretty often too, and frankly anything that
reduces the mental overhead of switching gears for each tool is good.
Even something small like this.

That being said, Matt has a strong point regarding scripts that rely on
the existing behaviour.  It's not cool to break people's automated tools.

	<b

Jonathan S. Shapiro <shap@eros-os.com>:
> Concur. If we are going to do this at all, it should be done before hg
> 1.0.0

And, on the flip side, I don't think it ought to be done after 1.0.0.
I consider a 1.0.0 release number to be a commitment about a lot of things,
including interface stability.

Which is why I say fix it now.  You've got one external tool developer
telling you it will help, and at this point only theoretical reasons to 
fear harm. And the longer you wait, the more likely it is someone will 
actually get stuck to the old interface.

BTW, something I hadn't previously mentioned: I had known that VC mode
badly needed a rewrite for years.  But it is very specifically wanting
to play with Mercurial that got me off my butt to actually do it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

No, the first actually reinforces the second. The options to show particular
states exist primarily for automation. Normal people just run 'hg st' and never
see the 'C' state.

We can't change the output of 'hg st' without an extremely good reason. It is
already used by numerous external programs and making Emacs VC mode slightly
tidier is not a good enough reason.

Nor is removing the slight confusion it causes to users (which judging by the
BTS is very slight indeed). It's about two years too late for this change.

Concur. If we are going to do this at all, it should be done before hg
1.0.0

On Sun, 2007-12-30 at 12:12 -0500, Eric S. Raymond wrote:
> Matt Mackall <mercurial-bugs@selenic.com>:
> > I'm not particularly keen on doing anything with this. First, as has been noted,
> > you don't see the 'C' state unless you ask to see it (by first reading the hg
> > status help and then using -C(!) or -A). Second, this is precisely the sort of
> > change that will break an external tool.
> 
> Your first objection undermines your second somewhat.
> 
> Anyway, I maintain one external tool that this change will actually help.
> That's Emacs VC mode, which benefits from status flags that are consistent 
> across VCSes.

Matt Mackall <mercurial-bugs@selenic.com>:
> I'm not particularly keen on doing anything with this. First, as has been noted,
> you don't see the 'C' state unless you ask to see it (by first reading the hg
> status help and then using -C(!) or -A). Second, this is precisely the sort of
> change that will break an external tool.

Your first objection undermines your second somewhat.

Anyway, I maintain one external tool that this change will actually help.
That's Emacs VC mode, which benefits from status flags that are consistent 
across VCSes.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

I'm not particularly keen on doing anything with this. First, as has been noted,
you don't see the 'C' state unless you ask to see it (by first reading the hg
status help and then using -C(!) or -A). Second, this is precisely the sort of
change that will break an external tool.

Changed to "=" in c2a21fe60994 of crew.

Mercurial does not track conflicts, it just calls hgmerge in such cases.
(There is the imerge extension, if you want to track conflicts)

Hm.  I didn't know of the Palm precedent.  I chose '=' because it seemed logical;
Subversion uses a space for this in its verbose status display, which we can't here.

Shap raises a good question.  I think "C' ought to be reserved for a conflict
status, igf you have one.  I'm only a novice at DVCSes, so I'm not sure exactly
what Hg's equivalent  of 'conflict' would be -- perhaps "this revision has a
sibling on the DAG"?

* Matt Mackall <mercurial-bugs@selenic.com> [20071228 16:35]:
> Is there precedent for '='?

THe backup program I use on my Palm uses this when verifying backup
sets.

Thomas

If another vote matters, I concur that 'C' should be avoided. I have no opinion
about the merit of '='.

However, while we are at it, should we consider using 'C' to mean "conflict",
consistent with other SCM systems?

Is there precedent for '='?

I have probably never run --clean so "=" is good for me

Even I sometimes got confused by C, not because its precedence in svn, but in cvs.

"=" would be ok for me. What do the others say?

The hg status codes are all upward compatible with Subversion's, except for the
use of "C" to mean a clean file.  This conflicts badly with Subversion's use odf
"C" to mean "conflict".  This objection has more force because Subversion codes
are a sort of de-facto standard now; bzr status --short emits them too.

This is a rarely-used status letter anyway; looks like it's only emitted with
the --clean option.  I suggest changing to something else -- maybe "=" would be
good.