1 |
On Thu, 4 Jan 2007, Alan McKinnon wrote: |
2 |
|
3 |
> On Wednesday 03 January 2007 20:24, Daniel Barkalow wrote: |
4 |
> |
5 |
> > I didn't say it shouldn't require interaction to get the new shipped |
6 |
> > version; I said it should require extra confirmation to discard |
7 |
> > changes made locally. It should also be able to offer 3-way merge |
8 |
> > instead of 2-way, and automatically retain local changes that don't |
9 |
> > conflict with shipped changes. |
10 |
> |
11 |
> Please define exactly what a "change that doesn't conflict with shipped |
12 |
> changes" means so that I can design a correct algorithm and implement |
13 |
> it in C or Python. |
14 |
|
15 |
Take the diff between the original version and the local version, and call |
16 |
this "local". Take the diff between the original version and the new |
17 |
shipped version, and call this "remote". Represent each of these diffs as |
18 |
a series of hunks. Step through the original file, and, by splitting on |
19 |
each hunk boundary in either of the diffs, produce a series of hunks, |
20 |
where each hunk has at least one version; if there is more than one |
21 |
version, ask the user for help in merging that hunk. The versions are: |
22 |
|
23 |
- the original, if neither side has any changes. |
24 |
- the local, if only the local has a change. (*) |
25 |
- the original and the remote, if only the remote has a change. (+) |
26 |
- the local and the remote, if both diffs have changes. |
27 |
|
28 |
When multiple versions are available, make it clear what those versions |
29 |
are, ask for additional confirmation if the choices are "local" and |
30 |
"remote" and the user picks "remote" rather than using "local" or writing |
31 |
a new version by hand. |
32 |
|
33 |
Also allow arbitrary edits to the file, in case the user has to fix up |
34 |
syntax. |
35 |
|
36 |
(*) Optionally, "the original and the local", if the user is particularly |
37 |
paranoid and wants to check over the purely local modifications. |
38 |
|
39 |
(+) This is the difference between this algorithm and RCS's "merge": |
40 |
changes made remotely can be rejected. |
41 |
|
42 |
> Include deprecated options, syntax changes, subtle changes in meaning, |
43 |
> redefined syntax commands and new conflicting options in config files |
44 |
> with the same name across version changes. make it bullet proof so that |
45 |
> any regular dev can list these things easily in confidence of their |
46 |
> correctness, where the user will know the impact without resorting to |
47 |
> looking it up every time, and where the correct thing (defined by |
48 |
> whatever $ARB_USER happens to believe they want) is done in the vast |
49 |
> overwhelming majority of cases. |
50 |
|
51 |
I don't think the paranoid user case is actually that significant. Either |
52 |
the shipped version has to compensate for the change in semantics, in |
53 |
which case there will be a remote change, which demands user interaction; |
54 |
or the shipped version doesn't change, in which case the current |
55 |
etc-update doesn't help you, because the shipped versions before and after |
56 |
are identical and emerge doesn't tell etc-update to do anything. |
57 |
|
58 |
Note that my algorithm never treats a file entirely automatically unless |
59 |
the current etc-update also would treat it entirely automatically. Mine |
60 |
just acts on a per-hunk level instead of a per-file level, and also |
61 |
provides additional information on what's going on. |
62 |
|
63 |
> I'm not jerking your chain here - that is the real spec of a system like |
64 |
> you propose. I'm not being pedantic and nit-picking - these are the |
65 |
> kind of detail things that make or break software. Windows Update fails |
66 |
> in the real world as Microsoft implements vast sweeping monolithic |
67 |
> changes leaving the user with no meaningful way to control the process |
68 |
> other than "do not apply SPx". Lets not even put one toe onto that |
69 |
> road... |
70 |
|
71 |
There's sort of a continuum of bad designs, from "no information and no |
72 |
control" to "no information and lots of control". It doesn't help the user |
73 |
much to have tons of control if there's no information to base a decision |
74 |
on. Think about how bad etc-update would be if it didn't tell you the |
75 |
filename you were working on. Microsoft does both of these bad things |
76 |
("stuff just happens, and the computer might not work" and "you have to |
77 |
make this critical decision: 'yes' or 'no'"). |
78 |
|
79 |
Gentoo is far better, but I think etc-update would be a lot better with |
80 |
more information given to the user; e.g., the choice for "replace the old |
81 |
shipped configuration with a new shipped configuration" should be a |
82 |
different key from "replace the locally-modified configuration with a new |
83 |
shipped configuration", rather than both being "replace the current |
84 |
configuration with the new shipped configuration". |
85 |
|
86 |
I don't actually mind the 100 files in etc-update all that much. The issue |
87 |
is that the first 99 are files I've never touched where I've never |
88 |
even learned the config file syntax, or the occasional executable in a |
89 |
weird place, or init scripts I haven't modified, or examples that aren't |
90 |
actually used, and the 100th one is my coworker's lovingly hand-crafted |
91 |
CUPS configuration, and I'm half asleep by the time I get to it. It should |
92 |
be able to tell that I've got local modifications, and warn me that I'm in |
93 |
danger of losing work on the config file. It's just kind of cruel to make |
94 |
me decide what to do with that file without mentioning this information. |
95 |
|
96 |
> The various update tools do the only realistic thing possible - the user |
97 |
> said to not touch these files, so it doesn't. Period. |
98 |
|
99 |
Well, then the user turns to etc-update for help in getting the files |
100 |
right. At that point, the system should do something, and it ought to be |
101 |
as helpful as possible. (Actually, I think that it would be even better to |
102 |
have the etc-update/dispatch-conf step done before the ebuild qmerge step, |
103 |
so that the user's chosen config file is merged at the same time as |
104 |
everything else, but that's another thing entirely.) |
105 |
|
106 |
> Now you are changing the goal posts. Previously you said the tools |
107 |
> should be doing automated changes. Now you say the tools should |
108 |
> highlight (as a diff perhaps) what the changes are. Which is it? |
109 |
|
110 |
I never said the tools should be doing automated changes. I thought that |
111 |
you thought that the *were* doing automated changes (because you said that |
112 |
they would only present you with files with local modification), and I was |
113 |
arguing that this claim was wrong; this has nothing to do with what they |
114 |
*should* be doing. I should have been more clear initially that I think |
115 |
automatically replacing locally-unmodified config files is a bad idea, in |
116 |
addition to not being the status quo. |
117 |
|
118 |
-Daniel |
119 |
*This .sig left intentionally blank* |
120 |
-- |
121 |
gentoo-user@g.o mailing list |