On Thu, 4 Jan 2007, Alan McKinnon wrote:
> On Wednesday 03 January 2007 20:24, Daniel Barkalow wrote:
>
> > I didn't say it shouldn't require interaction to get the new shipped
> > version; I said it should require extra confirmation to discard
> > changes made locally. It should also be able to offer 3-way merge
> > instead of 2-way, and automatically retain local changes that don't
> > conflict with shipped changes.
>
> Please define exactly what a "change that doesn't conflict with shipped
> changes" means so that I can design a correct algorithm and implement
> it in C or Python.
Take the diff between the original version and the local version, and call
this "local". Take the diff between the original version and the new
shipped version, and call this "remote". Represent each of these diffs as
a series of hunks. Step through the original file, and, by splitting on
each hunk boundary in either of the diffs, produce a series of hunks,
where each hunk has at least one version; if there is more than one
version, ask the user for help in merging that hunk. The versions are:
- the original, if neither side has any changes.
- the local, if only the local has a change. (*)
- the original and the remote, if only the remote has a change. (+)
- the local and the remote, if both diffs have changes.
When multiple versions are available, make it clear what those versions
are, ask for additional confirmation if the choices are "local" and
"remote" and the user picks "remote" rather than using "local" or writing
a new version by hand.
Also allow arbitrary edits to the file, in case the user has to fix up
syntax.
(*) Optionally, "the original and the local", if the user is particularly
paranoid and wants to check over the purely local modifications.
(+) This is the difference between this algorithm and RCS's "merge":
changes made remotely can be rejected.
> Include deprecated options, syntax changes, subtle changes in meaning,
> redefined syntax commands and new conflicting options in config files
> with the same name across version changes. make it bullet proof so that
> any regular dev can list these things easily in confidence of their
> correctness, where the user will know the impact without resorting to
> looking it up every time, and where the correct thing (defined by
> whatever $ARB_USER happens to believe they want) is done in the vast
> overwhelming majority of cases.
I don't think the paranoid user case is actually that significant. Either
the shipped version has to compensate for the change in semantics, in
which case there will be a remote change, which demands user interaction;
or the shipped version doesn't change, in which case the current
etc-update doesn't help you, because the shipped versions before and after
are identical and emerge doesn't tell etc-update to do anything.
Note that my algorithm never treats a file entirely automatically unless
the current etc-update also would treat it entirely automatically. Mine
just acts on a per-hunk level instead of a per-file level, and also
provides additional information on what's going on.
> I'm not jerking your chain here - that is the real spec of a system like
> you propose. I'm not being pedantic and nit-picking - these are the
> kind of detail things that make or break software. Windows Update fails
> in the real world as Microsoft implements vast sweeping monolithic
> changes leaving the user with no meaningful way to control the process
> other than "do not apply SPx". Lets not even put one toe onto that
> road...
There's sort of a continuum of bad designs, from "no information and no
control" to "no information and lots of control". It doesn't help the user
much to have tons of control if there's no information to base a decision
on. Think about how bad etc-update would be if it didn't tell you the
filename you were working on. Microsoft does both of these bad things
("stuff just happens, and the computer might not work" and "you have to
make this critical decision: 'yes' or 'no'").
Gentoo is far better, but I think etc-update would be a lot better with
more information given to the user; e.g., the choice for "replace the old
shipped configuration with a new shipped configuration" should be a
different key from "replace the locally-modified configuration with a new
shipped configuration", rather than both being "replace the current
configuration with the new shipped configuration".
I don't actually mind the 100 files in etc-update all that much. The issue
is that the first 99 are files I've never touched where I've never
even learned the config file syntax, or the occasional executable in a
weird place, or init scripts I haven't modified, or examples that aren't
actually used, and the 100th one is my coworker's lovingly hand-crafted
CUPS configuration, and I'm half asleep by the time I get to it. It should
be able to tell that I've got local modifications, and warn me that I'm in
danger of losing work on the config file. It's just kind of cruel to make
me decide what to do with that file without mentioning this information.
> The various update tools do the only realistic thing possible - the user
> said to not touch these files, so it doesn't. Period.
Well, then the user turns to etc-update for help in getting the files
right. At that point, the system should do something, and it ought to be
as helpful as possible. (Actually, I think that it would be even better to
have the etc-update/dispatch-conf step done before the ebuild qmerge step,
so that the user's chosen config file is merged at the same time as
everything else, but that's another thing entirely.)
> Now you are changing the goal posts. Previously you said the tools
> should be doing automated changes. Now you say the tools should
> highlight (as a diff perhaps) what the changes are. Which is it?
I never said the tools should be doing automated changes. I thought that
you thought that the *were* doing automated changes (because you said that
they would only present you with files with local modification), and I was
arguing that this claim was wrong; this has nothing to do with what they
*should* be doing. I should have been more clear initially that I think
automatically replacing locally-unmodified config files is a bad idea, in
addition to not being the status quo.
-Daniel
*This .sig left intentionally blank*
--
gentoo-user@gentoo.org mailing list
