[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