[Unison-hackers] list of unison issues / todo list
Frederik Eaton
frederik at ofb.net
Tue Aug 18 16:44:08 EDT 2015
Hello Unison Hackers,
I've been using Unison successfully in spite of the path.ml bug (which
perhaps only affects single-file roots?). It mostly works fine for me,
but I figured that it might be useful for me to make a list of minor
problems that I run into, in case someone decides to continue with
Unison development. I'm attaching my list to this message and also
made a 'gist' on github.com as an experiment:
https://gist.github.com/70dfb7ff01d86fd8f300
I'm not sure how helpful that "gist" URL is... Also, I'm not sure how
helpful it is to make a TODO list, I hope it encourages rather than
discourages further work on Unison. Anyway, perhaps if somebody with
write access to Unison could indicate agreement with some or all of
the items on the list, then that would be a first step to getting them
worked on.
Thank you!
Frederick
P.S. I wrote this without first reading TODO.txt in the Unison
tarball:
https://webdav.seas.upenn.edu/viewvc/unison/trunk/src/TODO.txt?revision=506&view=markup
but I don't see any of the issues I've identified in there...
-------------- next part --------------
Unison TODO list
================
Here is a personal list of bugs and feature requests for the Unison
file synchronizer. These issues refer to the text-based user interface
(which is the one I use). At the time of this writing (18 August 2015)
the latest Unison version is 2.48.3.
To my knowledge, Unison is the most standard and straightforward file
synchronizer for Linux. Many people say they now use 'git' or some
other revision control software for situations where they would have
used "Unison" in the past, but I still find Unison to be preferable
for many tasks. In many cases, such as sharing configuration files
between systems, I am not interested in storing an annotated revision
history of changes I make. Using revision control to deal with
conflicts in my own files seems cumbersome. A file synchronizer like
Unison solves the problem with less hassle.
While reacquainting myself with Unison recently, I made a list of
problems that I ran into. It would be great if someone has time to fix
them!
### Path.ml bug ###
* For certain command-line options, such as 'backup' or 'merge',
running unison on two single-file roots triggers an exception
failure in 'path.ml'. Reported here in 2009:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517240 and here in 2015:
http://lists.seas.upenn.edu/pipermail/unison-hackers/2015-July/001849.html
According to my testing, this seems to affect Unison versions all
the way from 2001! However, the bug could also have been caused by
more recent changes in the O'Caml string library, we're not sure.
### Skipping and quitting ###
* The help text for 'g' (currently: "proceed immediately to
propagating changes") should make it clear that this will propagate
_all future recommended_ changes, rather than just the ones that the
user has already approved. The first few years I used Unison, I
thought that 'g' meant "I've approved changes to a number of paths
already, now I want to save my place by propagating just the changes
I entered, skipping the rest of the paths". Instead it seems to mean
"I want to propagate the changes I approved, as well as approving
and propagating all the changes that Unison is about to recommend to
me" - in other words "switch to batch mode now" - which seems less
useful. Because the user doesn't control the order in which
conflicts are presented, I don't see the value of being able to
switch from interactive to batch mode mid-sync.
This is a UI bug, but it could result in data loss in certain
situations by triggering unintended "batch" syncs which propagate
changes in the wrong direction. It potentially affects not only
beginning users, but also experienced users who have read the entire
documentation, since it's not documented.
* Related to the above, there should be an option to "skip" all
remaining paths, for users who are satisfied with the changes
they've authorized so far and want save their work by propagating
these changes before continuing. Perhaps this should be what 'g'
actually does.
* There should be an option (or default) to ask for confirmation when
the user presses 'q' for 'quit', especially if changes have been
authorized. Sometimes I accidentally press 'q' and lose some work,
which is annoying. For instance, the results of 'diff' are usually
displayed to me in a pager, but sometimes there is no pager (e.g. if
I run unison with sudo). If I press 'q' out of habit to exit a
non-existent pager, it instead exits Unison. If I press 'q' twice by
accident, it exits Unison.
* The help list starts out with three "ignore permanently" commands,
which I think makes it easy to miss the fact that there is an option
to essentially "ignore the path temporarily" down at the bottom
("skip"). I would move the 'skip' option nearer to this group,
perhaps before it, in the Commands: help list, and perhaps rename to
'skip this path' for consistency with other command descriptions.
* Typing 'p' for 'previous' doesn't work after 'I' for 'ignore
permanently'.
### Paths ###
* The 'root alias' option would be more useful if I didn't have to
specify every possible "root" under a given directory or host. For
instance, if I'm aliasing //hostB// to //hostA//, I think that
should by default map //hostA/root1/ to //hostB/root1/ as well,
since the prefix matches. In the current version of Unison I need a
separate 'rootalias' option for subdirectories. This could be
annoying if, for example, I have several roots on a host and I want
to change the hostname.
* In diff output, it would be nice to be able to provide more
informative file names. Instead of this:
```
--- /home/frederik/.Xdefaults.unison.diff- 2015-07-30 17:17:20.353393267 -0700
+++ /home/frederik/.Xdefaults 2015-07-30 17:17:12.363370611 -0700
```
we could be looking at
```
--- //host1//home/frederik/.Xdefaults 2015-07-30 17:17:20.353393267 -0700
+++ //host2//home/frederik/.Xdefaults 2015-07-30 17:17:12.363370611 -0700
```
The GNU diff lets us specify these header path strings with the
"--label=" option. To allow us to make use of this feature, Unison
would need to give us the pretty path names in variables (e.g.
HOSTPATH1 and HOSTPATH2) for substitution in the 'diff ='
configuration option.
Also see:
https://wiki.archlinux.org/index.php/Unison#More_helpful_diff_output
This is a suggestion for making Unison's 'diff' output more
readable, which could be mentioned in the manual or turned into a
default.
* When a new file has been created in one root, 'd' for 'diff' should
display the contents of the file (e.g. by diffing against /dev/null).
* It's strange that "ignore = " allows pattern matching, but "path = "
does not. What if I want to use Unison to merge every dot file in my
home directory? The inability to use patterns to define groups of
files makes it difficult. I guess this is a very basic design
decision which would be difficult to change, but I noticed it has
been brought up before on the mailing list. As far as I can tell
from the documentation, 'ignorenot' does not serve as a workaround.
* If I accidentally put a pattern instead of a literal path into a
"path = " specification, the GUI gives me an error ("Filesystem
watcher error"), but the text-based interface doesn't even give a
warning. A warning would be nice.
### General interface ###
* When I first start Unison, I see hostnames written above two
columns. The columns may contain text like "changed" or "new file".
However, if I press 'd', or '?', or 'l', or if I simply go through a
lot of paths, I lose the host names header, and then I get '>' and
'<' confused. It would be convenient if various commands which
produce lots of output would finish by printing the column headers
again as a reminder.
* I tried to use 'merge = ' to specify a merge command which runs in
the terminal, but this didn't work. Instead I had to make the
command open an xterm with my merge program running inside it. It
would be nice for Unison to give the 'merge' command access to the
terminal. This would provide a simpler interface, and make debugging
the merge command easier. Of course, GUI users would have to provide
a different merge command.
More information about the Unison-hackers
mailing list