[darcs-users] Patches dependency discovery

[Leif Frenzel]

>>Still it is good to have a tree that reflects dependencies. It gives the 
>>user a quick overview of what he would have to select in order to get a 
>>particular patch. But having the leaves as root elements would mean that 
>>the user would have to expand all the tree to find patches that precede 
>>the others.
> 
> 
> That's why I'm suggesting putting all patches at the root. So your
> example above would become:
> 
> A
> 
> B - A
> 
> C - B - A
>   |
>   - D - A
> 
> D - A
> 
> That is, I imagine the typical use case to be 'I want to pull patch X,
> and need to know which other patches I have to pull as well'. 
That may be the typical case for push, where I know which patches are in 
the list in advance (because I have recorded them). For pull, I get a 
list from the repo, and I don't think it is the typical case that I 
already know that list and know which of the patches in the list I want 
to pull.

 >That is
> made very easy using the arrangement above, since X can always be
> found at the top level, and the dependencies of X are all its
> children. I don't see the list of patches that depend on X as being
> terribly useful information.
It may be useful not to see them, though, or more precisely: only see 
them if I like. Getting a list of all patches, which may be long, forces 
me to scan them and possibly to scroll the dialog (or whatever window 
they are on); if they are in a tree below the root node, I have to 
expand them only if the root node seems acceptable or interesting to me.

Only in the case when I have a special patch in mind or want to 
cherry-pick from the list I want a different view. For this I could 
switch to flat view (or we could have a filter like in the Eclipse 3.1 
preferences dialog).

> By contrast, using the arrangement you show, I need to already know at
> least one of C's immediate dependencies in order to actually find C.
> 
> That's true for pulling at least. For unpull, the situation reverses,
> so probably in the long term both views should be available (but
> again, all patches should appear at the root, and no automatic
> ticking, please).
Can't see how to avoid it. If not for ticking, then for un-ticking. For 
instance if we have A > B. Initially, A and B are unchecked and B is 
disabled. Check A, so B gets enabled. Now check B. We have two 
possibilities: either we disable A (in checked state) or we don't. If 
the latter, the user can uncheck A, which would force us to uncheck B 
automatically. I the former, that's no good, for now I can get into the 
situation that there is a checked disabled patch that I would like to 
uncheck, but first have to figure out which others I must uncheck 
elsewhere to get it enabled again. In the simple case, that's only B. In 
the example above, suppose C is checked and disabled, because all it's 
dependencies are checked. Now you have manually to go through the entire 
dependency tree below C and locate A, B, and D in the list at the top 
level and uncheck them. And that's bad too.

Apart from that, some people like it if the number of clicks they have 
to do is reduced. If I select something that has dependencies, there is 
nothing I really can decide about these. I just have to select them, and 
that can be done automatically as well as manually. And this is a common 
UI paradigm. It's everywhere in the Eclipse export wizards, where you 
want a file to be exported, all parent folders are selected 
automatically. This is not an exact parallel, of course, because of the 
multiple parents that we have in our case, but apart from that special 
problem, it's perfectly common UI behaviour.

> Regarding GEF: if you try the script I wrote, you'll see that Graphviz
> (which AFAIK is considered best-in-class for open-source software
> which does this) does a pretty mediocre job of laying out the graph,
> and scales poorly to large graphs. So, don't expect miracles if you
> actually try to show the complete graph. Some sort of simplified view
> is probably inevitable.
Yes, I agree. I'd prefer a list or tree with checkbox items over a 
special graphical drawing.

Ciao,
Leif

> 
> -- Jamie Webb
> 
> _______________________________________________
> darcs-users mailing list
> darcs-users at darcs.net
> http://www.abridgegame.org/mailman/listinfo/darcs-users
> 
>