Re: [Monotone-devel] [bikeshed] once more on bookkeeping dirs...

[Daniel Carosone]

On Tue, Mar 14, 2006 at 11:17:49PM -0700, Derek Scherger wrote:
> I seriously think we should decouple the renaming of things from the 
> 0.26 release. Since all of this is so bike-shed-y anyhow, there's no 
> sense rushing into something silly for the sake of this one, already 
> big, release.

I tend to agree.  We have this iface-refactor branch which might
invoke other significant user-visible changes in the way things work,
and the naming of subcommands, and such.  It seems sensible to me that
at the point that lands, we rename stuff to represent the UI flag day
(or even have compatibility code under the old name, if someone really
feels the need).

The counter argument that we're going to be breaking people's
workspaces because of rebuilding revid's (and MT/work) seems weak.
Apart from this one-off inconvenience, one of the nice things about
rosters landing and the 0.26 code as it presently stands is that it
*doesn't* change much if anything about what the user sees.  We can
quite honestly say this release is about lots of good, sound,
important and interesting internal changes and fixes that you mostly
won't have to worry about unless you want to.

That has a a kind of cleanliness and reassuring nature to it: it seems
much less worrying for users who just want to get their projects done,
using monotone, especially if the idea of large internal changes makes
them nervous.  They know that they won't have to relearn expected
behaviour or usage patterns in order to figure out whether something
went wrong.

I know renaming things isn't a big deal, but it is.  It's visible
change, just when it would be best to say "it works just like before,
but much better".  We even don't have the --merges/--no-merges UI
change we experimented with on mainline for a while.

There is one UI exception to this, with the new attr handling.  That's
such a huge win, especially on projects where a large proportion of
files are binary / manual_merge. I lead a project like this, and it's
a royal pain; making it go away is no threat to UI comfort and
expectations.  In most cases, we just stop asking for merge assistance
for .mt-attr, and probably users just stop noticing the previous wart
and only notice that "merges work much better now" (for several
reasons related to the internal changes, attr related or not).

> None of what we've seen is any better, or any worse, than 
> what we already have. People will probably complain either way but since 
> there isn't much in the way of consensus perhaps the status quo is the 
> right thing for now.

I tend to agree with this, too.

If anything else (other than bug and doc fixes and tests) is to fit in
with 0.26 as it stands now, it would be rev salts if we need them.
Otherwise, I really think we just want to get it out the door; 0.25's
deficiencies are hurting.

--
Dan.

pgpw36GxmjwgW.pgp
Description: PGP signature