TODO.txt (37851B)
1 Here we list planned and imagined improvements to Unison. Ones that we 2 regard as most important are marked with more *s. (Note that, since Unison 3 is no longer under active development [though it is still heavily used by 4 its original developers], the presence of a suggestion in this file is not 5 promise that anybody is going to implement it!) 6 7 ########################################################################### 8 9 * CURRENT 10 * ======= 11 12 * Make some preferences per-host 13 - file-system type 14 - canonical name of the host 15 - fastcheck 16 - backup 17 - fs watcher command 18 19 * Work on the Unison side 20 - create temp file 21 - start watcher based on watcherosx switch, passing all paths as args 22 - on each loop 23 - parse results into shallow and deep ones 24 - combine the two lists (marking which is which) 25 - sort the list 26 - if there are any adjacent pairs where the first is a prefix of the 27 second, drop the second and mark the first as deep 28 - go through the list and drop any item for which any PREFIX of 29 its path matches 'ignore' and doesn't match 'ignorenot' 30 - bulletproof, handling fatal errors and restarting completely from 31 scratch if necessary 32 33 * The directory scanning optimization is currently disabled under Windows, 34 as FAT partitions do not have directory modification times. 35 we could check whether we are on an NTFS partition by calling 36 GetVolumeInformation to get the filesystem name. 37 38 * We could defer most fingerprint computations to the propagation phase; 39 this would improve the user experience and save some fingerprints: 40 - do not compute fingerprint of new files during update detection 41 - during reconciliation, try to decide what to do based on what is 42 known so far 43 - for undecided paths (two files), request checksums (in batch) 44 - hashes are finally computed during propagation 45 46 ########################################################################### 47 48 * SOON 49 * ==== 50 51 **** Document: root, fspath, path (local/not) 52 53 **** Nice code cleanup trick: Add a phantom type param to Pref (and Pred?) 54 that prevents mutation from outside the module where the preference is 55 defined (by exposing it with a weak type). 56 57 *** Un-writeable directories can't be copied. 58 The 'rename' operation at the end of Files.copy will fail (at least on 59 OSX) if the path being renamed points to a directory and that directory 60 (not the one containing it!) is not writeable by the user. To fix this, 61 we'd need to notice when we are renaming a directory and temporarily 62 make it writeable just before the rename and then make it what it should 63 be just after. But I don't feel like writing this bit of code right 64 now, to handle such a corner case. [BCP, November 2008] 65 66 *** [Marcus Sundman, 2008] Unison can't propagate changes in read-only 67 folders. The correct way to do it is to temporarily add write 68 permissions for the user to the folder, then do the changes and then 69 reset the permissions. Now unison tries to just do the changes, which 70 fails with a "permission denied" error. 71 72 It would be nice if Unison could have the "power" to copy write-protected 73 files, maybe as an option. 74 75 *** Fix the pred module to understand negation and delete XXXnot predicates 76 77 *** Web 78 - Add a "supported platforms" page mentioning system-specific stuff 79 - Add an installation instructions page, removing it from the manual 80 81 ** add '<meta http-equiv="expires" content="0">' 82 to the head section of all the unison web pages. 83 84 *** See if we can get rid of some Osx.XXX stuff (e.g. ressLength!?) 85 86 * There is no way of selecting files with wildchar. I had to use 87 ignorenot = Name opt/root/.unison/*.prf 88 ignore = Name opt/root/.unison/* 89 But this is inconvenient, but the worse is that it gets complicated very 90 fast and I cannot make it for more complicated scenarios. I would expect 91 something like (suggestion): 92 Files = opt/root/.unison/*.prf 93 94 * When synchronizing FAT32, there could be an explicit command for 95 ignoring attributes. The problem happens when one side is FAT32 but the 96 other is not, or when mounting parameters are different. 97 98 99 * MERGE FUNCTIONALITY 100 * =================== 101 102 * Merge issues: 103 - It would be better to ignore the exit status of the external merge 104 tool and just look at what files it produced to decide what happened 105 - The function that runs the external program should not grab stdin / 106 stdout / stderr if Unison is running with the text UI. 107 - The confirmation step should offer to display the new merged file. 108 - (There are some older merge issues documented below) 109 110 **** Remaining problem with merging code: 111 - create two directories, each containing a .txt file 112 - sync so they are equal 113 - change the file so that one region is in conflict and another 114 region has changes that can be propagated correctly 115 - sync 116 - now we should be able to change the second region in just one file, 117 sync again, and see the change propagate; instead, it conflicts 118 - diagnosis: the merge stuff is not correctly updating the archive in 119 the event of a partial reconciliation 120 121 ** An idea for the interface to the external merge functionality: 122 created a general mechanism for invoking external functionality... 123 - in profile, declare a command of the form 124 key M = external "merge ##1 ##2 ###" --> overwriting originals 125 (concrete syntax open to discussion!). Main parts are 126 - what key to bind it to in the UI(s) 127 - the command line to start up 128 - variables (##1 and ##2) for the local and remote files 129 (the remote file will automatically be copied to a local temp 130 file, if this variable is used) 131 - a variable (###) for a temporary output file 132 - an indication of what to do with this output file 133 (or maybe this could be automatic) 134 - (should also indicate which machine(s) to run the command on?) 135 136 ** small additions to merge functionality: 137 - if the external merge program *deletes* one of the files it is given, 138 Unison should interpret this as "Copy the other file onto this location 139 (instead of merging)". This will allow some other interesting 140 functionality, e.g. external programs that may decide to keep both 141 versions by moving one of them out of the way (mh-rename). 142 - the invocation of the external 'diff' program should be selectable 143 using the same conventions as the 'merge' program 144 - would be nice to be able to invoke DIFFERENT merge programs 145 depending on paths 146 147 ** We should document other available merge tools, e.g., 148 idiff [BCP has a copy of the code for idiff that Norman sent.] 149 150 ** Suggestion for extending merge functionality 151 - add a new kind of preference -- a conditional stringlist preference 152 - in the preference file, each value looks like either 153 prefname = string 154 or 155 prefname = string WHEN Path PPPPP 156 prefname = string WHEN Name XXXXX 157 prefname = string WHEN Regex XXXXX 158 - when we look up such a preference, we provide a current path, and it 159 returns the one that matches the current path, if any 160 161 162 * BUILDING AND INSTALLING 163 * ======================= 164 165 166 167 * DOCUMENTATION 168 * ============= 169 170 ** Add something to docs about how to use 'rootalias'. Include an 171 explanation of the semantics, a couple of examples, and a suggestion 172 for how to debug what it's doing by turning on appropriate debugging 173 flags. (And maybe we should actually make the debug output there a 174 bit more verbose?) 175 176 ** Misc: 177 - document good trick: use -1 switch to ssh if the paths are set up wrong 178 on the remote host 179 - should say whether trailing slashes are ok for paths; should say 180 that leading slashes are illegal. 181 ===> check 182 - not so clear what you have to do with a Regex to match a directory 183 and all its subfiles: foo or foo/ or foo/.* ? 184 ===> the first. document it. (Does foo/ match foo? I don't think so. 185 Document, one way or the other.) 186 - what happens when files are included whose parent dirs are 187 excluded? (With Regex? With multiple Path and Name?) 188 ===> document 189 - the documentation is very good, but i couldn't find a description of how 190 to respond to the prompts in the textual ui. is that explained 191 somewhere? 192 193 194 * SMALL FUNCTIONALITY IMPROVEMENTS 195 * ================================ 196 197 **** Please let me say 198 root = ~/bla 199 instead of requiring me to give an absolute path to my home dir. 200 201 ** ~/foo seems to work on the command line but not in root = ~/foo in the 202 config file. 203 -- 204 Similarly: It seems that when one specifies logfile = foobar 205 in the preferences file, then unison assumes that it is relative to the 206 current directory. Since neither ~ nor $HOME are understood in the 207 preference file, this is an inconvenience, because it forces the user to 208 remember to run unison from the root directory. 209 ===> Would be nice to support ~ internally 210 211 *** [Adrian Stephens, 2007] I would like the scope of rootalias to be 212 expanded so that any command that expects a root will perform aliasing 213 on the command. In my application, I need to change the root statement 214 as I move my machine from desk to the road. I also have a "force" 215 statement, and I also have to remember to edit this to match. It would 216 be more convenient to have to edit in a single place and, more 217 importantly, avoids introducing any inconsistency. 218 --- [BCP:] I like this idea. However, since I'm struggling at the 219 moment to find time to finish polishing 2.27 to become the new stable 220 release, I am not going to undertake to implement it. If you (or 221 someone else) would like to give it a shot, here is what I think needs 222 to happen: 223 - Move the rootalias preference and the rootalias-expanding code from 224 Update.root2stringOrAlias into the Common module (creating a new 225 function there for rootalias expansion). 226 - Find places like Recon.lookupPreferredRoot that deal with names of 227 roots and add a call to the rootalias-expanding function. 228 229 *** Delete old backups mechanism and, instead, extend new one to cover its 230 functionality 231 - put backups in same dir as files by default 232 - otherwise, put them in a central place if one is given 233 - Update.incrVersionsOfBackups should not be externally visible 234 235 *** unison -help doesn't go to stdout so it's hard to pipe it into less 236 ===> Probably *all* output should go to stdout, not stderr (but maybe 237 we need a switch to recover the current behavior) 238 239 * Maybe we should write debugging and tracing information to stdout 240 instead of stderr? 241 242 *** If a root resides on a `host' with an ever and unpredictably changing 243 host name (like a public login cluster with dozens of machines and a 244 shared file system), listing each possible host name for this root is 245 not feasible. The ability of specifying patterns in rootaliases would 246 help a lot in this case. I'm thinking of something like this: 247 rootalias = //.*//afs/cern.ch/user/n/nagya -> 248 //cern.ch//afs/cern.ch/user/n/nagya [NAGY Andras <nagya@inf.elte.hu>, 249 March 12] 250 ===> We definitely ought to do something about this problem -- it's 251 increasingly common. Not sure if this is the right proposal, but 252 something. 253 254 *** Currently, if a file changes on either side between the initial update 255 detection and the time when the transport module tries to propagate 256 changes, the transport is aborted. But if the change occurred on the 257 replica that is being used as the source for the transfer (which will 258 be the common case!), then there is no reason to abort -- we should 259 just propagate the newest version. 260 261 *** When unison notices lock files in the archive directory, it should 262 offer to delete them *for* the user, rather than forcing the user to 263 delete them manually. 264 265 *** There is no command-line argument to tell Unison where the .unison 266 directory is; Unison finds it in the environment or not at all. I was 267 able to workaround this with a symbolic link to put .unison where it was 268 expected, but it seems like an easy option to add. 269 270 *** The other is possibly a bit more difficult, but more useful as well. There 271 is a brief window of vulnerability between when the local server is started 272 and when the remote client connects to it. (It's no longer than that 273 because Unison won't take more than one connection at a time.) I can 274 tolerate it, but the window could be eliminated entirely by allowing socket 275 connections to require a nonce. 276 277 ** Allow 'default.prf' in place of 'default' for profile names 278 279 ** [dlux@dlux.hu, Feb 2002] For some apps (e.g., some mail readers?), 280 putting temp files in the same directory as the file we're about to 281 overwrite is bad/dangerous. Some alternatives that we could 282 consider... 283 - Add a configuration option for temporary directory and notice the 284 user about the volume restrictions in the docs and then if the user 285 does not consider it, then we use a non-atomic (copy + unlink) 286 rename. In an ideal environment (where the user consider this 287 restriction), it makes possible to sync a maildir folder while it is 288 online! 289 - An even better solution: One more temporary file step. If the user 290 sets the temporary directory, then we synchronize the files to that 291 directory, and if the file is downloaded/uploaded fully, then we move 292 it to a tempfile into the target directory (with .unison.tmp 293 extension) and then rename it into the final name. 294 295 ** Would be good to (optionally) change the semantics of the "backup" 296 functionality, so that Unison would not insist on making a *full* 297 backup of the whole replica, but just do so lazily. (I.e., it would 298 not make backups when files get put into the archive, but only when 299 they actually get changed.) 300 301 ** Would also be nice to allow the backup preference to be set 302 differently on different hosts -- so that all the backups could be 303 kept on one side (if there is no space on the other side, e.g.). The 304 obvious way to do this is to add a switch like '-suppressbackupsonroot 305 BLAH' but this feels a bit ad hoc. It would be nicer to decide, in 306 general, which preferences can sensibly have different settings on 307 different roots (e.g., the location of the archive dir, ...) and 308 provide a general mechanism for setting them per-host. 309 310 ** no spec for escaping regexp chars; spaces? newlines? tabs? others? 311 mechanism for getting the list of files from another program (plugin)? 312 ===> needs to be documented (look at rx.ml) 313 314 * [July 2002, S. Garfinkel] Maybe we should turn the 'time' option on by 315 default. We might need to help people a little on the upgrading, 316 though. When you did a sync with time=false, then a sync with 317 time=true, you get a zillion conflicts... 318 ==> This is probably a good idea, but I'm a little scared of all the 319 messages we'd get from upgrading users 320 ==> Also, "make" can get confused when the 'time' option is set 321 322 * URI pathname syntax 323 Why is the following command wrong? 324 unison -servercmd `which unison` /usr/local ssh://labrador/usr/local 325 It took me three tries and careful reading of the documentation to 326 figure it out. I don't have any good suggestions here, other than 327 that I think the whole issue of relative vs absolute pathnames needs 328 serious thought. I think the current interfaces do not work very 329 well. One possibility that I will float is that you invent a special 330 character string to refer to the root of synchronization. 331 E.g., interpret ~ as $HOME in roots. 332 -- 333 Also: we should add the file:// syntax to URIs... 334 file://C:/Necula (C:/Necula on the local file system) 335 file:////share/subdir (//share/subdir as from the point of view of 336 the local file system) 337 unison://host///share/subdir 338 -- 339 Should local roots in a profile be canonized? 340 Right now, we can have a relative root in the profile. This 341 is going to be a problem if unison is started in a different 342 directory. 343 344 * At the moment, if Unison is interrupted during a non-atomic operation 345 on the file system, the user has to clean things up manually, following 346 the instructions in the the recovery log. We should do that for them. 347 (This is actually a bit tricky, since we need to be careful about what 348 might happen if unison crashes during recovery, etc. The best way to 349 accomplish this would be to write a general logging/recovery facility 350 in OCaml.) 351 352 * Dealing with ACLs: Maybe this is what we should do actually. We could 353 specify a user (and similarly a group) to unison. It would be 354 interpreted in a special way: if a file is owned by this user, unison 355 will rather consider that the owner of the file is undefined. So, when 356 a file owned by an unknown user is synchronized, the file owner is set 357 to the default user. Then, on the next synchronizations, unison will 358 consider that the owner has not been propagated and try again. [Should 359 be easy once the reconciler is made more modular] 360 361 * The -terse preference should suppress more (in fact, almost all) 362 messages in the text ui. See Dale Worley's message for a detailed 363 proposal. 364 365 * [Joerg von den Hoff, 2009] I use unison (up to now) only from the command 366 line and it's used from within scripts or Makefiles. it is therefore 367 unfortunate that by default the GUI pops up and one has to use `unison -ui 368 text' to avoid this. it would seem better to have it the other way round, 369 i.e., to make the CLI the default and to require `unison -ui graphic' to 370 start up the GUI from the command line (I would argue that people using the 371 GUI regularly will start it anyway by double clicking the app) 372 373 add a switch '-logerrors' that makes unison log error messages to a 374 separate file in addition to the standard logfile 375 376 Update checking over NFS might be *much* faster if we use only relative 377 pathnames (absolute paths may require an RPC per level!?) 378 379 [Ben Wong, Aug 2002] Why not make unison fall back to addversionno if it 380 would otherwise bomb out with an incorrect version number? That way I 381 wouldn't have to educate people on how to use Unison at my site; it'd 382 "just work". 383 384 The -sortbysize is nice, but what I would really like is a -limitbysize. 385 When I'm connected over a modem line, I would like not to transfer the 386 larger files that need synchronization. That can wait until I am 387 connected via a faster connection. What I presently do is allow unison 388 to run in -sortbysize mode, and abort once I have all my little, more 389 important files. -limitbysize should simply filter the list of transfer 390 to only those that are below the threshold size. The syntax is 391 obvious... It should be -limitbysize xxx, where xxx is the size 392 (preferably in kb, but bytes will do as well). 393 394 [From Yan Seiner] 395 Can unison modify the (*nix) environment to show the 396 ip/name/some_other_id of the system making the connection? This would 397 help tremendously. 398 For example, vtun does this: 399 --- 400 root 6319 0.0 0.6 1984 852 ? S< Aug27 0:37 vtund[s]: 401 bgsludge tun tun10 402 root 6324 0.0 0.6 1984 852 ? S< Aug27 2:00 vtund[s]: 403 cardinal tun tun0 404 root 17001 0.0 0.6 1984 848 ? S< Aug27 0:05 vtund[s]: 405 wtseller tun tun11 406 root 20100 0.0 0.6 1984 852 ? S< Aug28 0:02 vtund[s]: 407 cardridg tun tun1 408 ---- 409 So I know I have four sessions, to each named machine, and I know 410 immediately who is connected and who is not. If I have to kill a 411 session, I don't kill the wrong one. 412 413 Dale Worley's suggestion for relocating archives: 414 > You're right: it's not all that tricky. So would you be happy if you 415 > could run unison in a special mode like this 416 > unison -relocate //old-host1//path1 //old-host2//path2 \ 417 > //new-host1//path1 //new-host2//path2 418 > (where all the hosts and paths are normalized) and it would move the 419 > archives for you on both machines? 420 Actually, I think that what you want is for the user to specify the 421 old paths in *normalized* form and the new paths in *non-normalized* 422 form. That is, unison uses the old paths literally as provided by the 423 user, but it applies the usual normalization algorithm to the new 424 paths. 425 This may sound strange, but I think that it's the Right Thing: 426 - There is no guarantee that the normalization algorithm, applied to 427 the old paths as the user used to specify them, normalizes to the 428 the normalized paths that are recorded in the archive. Indeed, 429 there may no longer be *any* path which normalizes to the recorded 430 paths. 431 - The user can extract the normalized old paths from the second line 432 of the archive files. This is clumsy, but reliable. And we don't 433 intend the user to relocate an archive very often. 434 - But for the new paths, you want to normalize what the user supplies, 435 because he doesn't know in advance how Unison is going to normalize 436 the new paths, and may well specify them incorrectly. That would 437 leave him with a relocated archive that he might not be able to use 438 at all. 439 You might want to put quotes around the pathnames in the second line 440 of the archive, since MS-Windows directory names can contain spaces, 441 etc. 442 443 Would be nice to be able to run unison in a special mode like this 444 unison -relocate //old-host1//path1 //old-host2//path2 \ 445 //new-host1//path1 //new-host2//path2 446 (where all the hosts and paths are canonized) and have it move the 447 archives for you on both machines? 448 449 For safety... 450 - Add a preference 'maxdelete' taking an integer parameter, default 100 451 (or perhaps even less -- keeping it fairly small will help naive users 452 avoid shooting themselves in the foot). A negative number means 453 skip this check (i.e., infinity). 454 - When the transport subsystem gets control (i.e., just after the user 455 says 'go' to the user interface, when not running in batch mode) 456 it first checks the number of files that are going to be deleted 457 (including all the contents of any directories that are marked for 458 deletion). If it is more than maxdelete (and maxdelete is 459 positive), then... 460 - If we're in batch mode (batch=true), we halt without doing 461 anything. 462 - If we're not in batch mode, we display a warning message and 463 make the user confirm. (If they do *not* confirm, it would be 464 nice to dump them back into the user interface again, but this 465 would require a little rewriting of our control flow.) 466 - Would also be nice to include a display in the UI someplace that says 467 how many files are to be deleted/changed/created plus how many bytes 468 to be transferred, and a warning signal (display in red or something) 469 if these exceed the current setting of maxdelete. 470 471 It would be nice if unison had a tool by which it could regenerate all 472 the MD5 sums and compare them to what it has stored, then produce a list 473 of files that are different. I obviously cannot count on file size and 474 date in this case; those may not have changed but the contents may be 475 corrupt. 476 477 If the connection to the server goes away and then comes back up, it 478 would be nice if Unison would transparently re-establish it (at least, 479 when this makes sense!) 480 481 Better documentation of the -backups flag, and a way to expire old backups 482 483 Add a preference that makes the reconciler ignore prefs-only differences 484 between files (not updating the archive, though -- just suppressing 485 the difference -- will this slow things down too much?? Maybe it needs 486 to happen in the update detector, before things are transmitted across 487 the network.) 488 489 Perhaps we should interpret both / and the local separator as path 490 separators, i.e., under Windows / and \, under Mac / and :, and under 491 Unix just /. For Windows this will be fine, since / is not allowed in 492 filenames. 493 494 Maybe we should never emit a conflict for modtimes; instead, we just 495 propagate the largest one. 496 497 [Ivo Welch] I would do a quick test of case sensitivity in the program 498 itself at the time you do a first prf sync, so that the user does not have 499 to bother with it. Just write two files on each end which differ in case, 500 and see if there is overwriting. Then do the smart thing. The long-named 501 file in the .unison directory should keep this information thereafter. 502 (BCP: Implementing this is more difficult than it might seem. E.g., 503 whenever a symlink is followed we might need to go through the same 504 exercise. And then we'd need to be able to deal with replicas that are not 505 all one way or the other...) 506 507 [Ivo Welch] I would give some examples in the man page of what an xxx 508 specification is. 509 510 [Ivo Welch] I would allow '--' switches, in addition to the '-' switch spec. 511 512 [Ivo Welch] On OSX, create a link from ~/Library/Application Support/Unison 513 to .unison, just for ease of finding it. It took me a long time to find my 514 .prf files. 515 516 [Ivo Welch] the OSX GUI front end should be clear which side (left or right) 517 the local host and which side the remote host is. 518 519 * USER INTERFACE 520 * ============== 521 522 ** in gtk ui, display green checkmark next to finished items even if their 523 direction indicates a conflict; do not list such items as "skipped" at 524 the end 525 526 ** In both UIs, show how many bytes/files were successfully transferred 527 at the end 528 529 ** Should support auto-termination of the graphical UI (switch-controlled) 530 * Unison starts in the usual way and checks for changes 531 * If there are no conflicts, it proceeds without waiting for confirmation 532 * If there *are* conflicts, it waits for instructions, just like now 533 * In either case, when it's finished transferring the changes, it quits 534 535 * [Matthew Swift] in the GTK gui at least, 536 display the total MB or #files or whatever it is that the ticking 537 %-meter is referring to when it goes from 0 to 100. it is useful to 538 know how big the xfer is going to be before starting it (might induce me 539 to choose "sort by size", or abandon and choose a smaller subset, etc.). 540 Also, esp. since the gui is single-threaded and unresponsive, i would 541 like to know what size of a synch that I am for example 50% or 22% 542 through. I know that an ETA and other things we're used to from many 543 downloading apps would require quite a bit of code, but it would help a 544 lot just to display whatever constant is represented by 100%. 545 546 547 * [BCP] Error reporting for per-file problems during updating leaves 548 something to be desired. In particular, there's no indication even of 549 which host the problem occurred on. (I added something that includes 550 "root 1" or "root 2", but I'm not sure that's better than nothing.) If 551 there are errors on both hosts, only one will be reported. If there 552 are lots of errors in a subdir, only the first will be reported. 553 Recon.propagateUpdates would be a starting point for changes. 554 555 * [Jamey Leifer] 556 [graphic ui, wishlist] The documentation topics aren't searchable. As 557 a result "unison -doc running | less" is still indispensable if one 558 wants to find anything. I suggest adding a box 559 560 "search in this topic: ---" 561 562 which is always available in the doc viewer. It would be nice to 563 support keyboard shortcuts in the "less" style, namely "/", "n", and 564 "N" (i.e. search, next, previous) to avoid too much clicking. 565 566 [graphic ui, wishlist] Ditto as far as searchability for diff reports. 567 568 * Would be nice to have a keystroke in the UI that means 'add the current 569 directory to the set of ignore patterns.' 570 571 * In the text UI, during the transport phase, print each file being 572 transferred on *one* line, with an arrow to indicate which way (and 573 dropping the explicit indication of which host from and to). The 574 logfile should be more explicit. 575 576 * The unison gui currently displays a percentage completion in the lower right 577 corner. I would find it comforting if it would also display an effective 578 bandwidth there, i.e., how many bits per second are flowing through the 579 transport layer? I make this request because owing to a hardware 580 catastrophe, I have just started using Unison through the phone lines, and 581 it seems to do nothing for a long period of time. I don't know whether 582 to blame the cheap modem, the cheap ISP, or whether Unison simply isn't 583 telling me that bits are flowing through the wire. (netstat -tn 584 suggests not much is happening, but I don't know if the results can 585 be trusted.) 586 587 * Would it be hard to add "tool tips" to the buttons in the UI? 588 ==> Look for "tooltip" in examples/testgtk.ml. 589 The easiest way is with a toolbar, but you can also add tooltips to any 590 widget (cf lines 867 and after). 591 592 * > On a line, I would like to have a description of the action to be taken in 593 > clear words: (e.g. will erase file on local or will copy from local to 594 > remote, etc.) 595 This might be a good use for "tool tips," if I knew how to make them work 596 using lablGTK. 597 598 * The menu help for left/right arrow both said `transfer local to local'. 599 Not helpful. The items in question are pathnames, which you might not 600 have to abbreviate. To save space one might consider replacing any 601 common prefix, and also short prefixes that look like they might be 602 automounter goo, with an ellipsis. Then show, e.g., 20 chars. I'd 603 also be willing to name paths in my profile, e.g., replica flatcoat = 604 /home/cellar/nr replica cellar = /m/cellar60/nr This would be 605 especially attractive if my short names were meaningful on the command 606 line. 607 608 * In the GTK user interface, it would be nice to be able to put up a window 609 displaying the contents of the log file (and add log messages to it 610 dynamically as we're working). Be careful, though: the log could get 611 large and we don't want this to be too slow. 612 613 * Could there be an option between -ui text and -ui graphic that when combine 614 with -batch and -auto would start in text mode, but pop up an interactive 615 graphic window when real conflicts happens. 616 617 * [Jamey Leifer] I think "unison -doc" should be mapped to "unison 618 -doc topics" and the error message for the former eliminated. 619 620 Unison's gui offers an `Actions' menu with a variety of features 621 regarding preferences. I would love to see an action with the following 622 semantics: if the two files differ only in their modification time, 623 prefer the older modification time. 624 ===> This would be easy to add, but I am beginning to worry that we are 625 getting too many funny little switches like this. We should think 626 about them all together and make sure they make sense. 627 628 I'm watching it sync a very large file that I don't want anyway, and I'm in 629 a hurry. I'd like a way to say "forget that file, I don't care about it, go 630 on to the next one you have to sync". Doesn't sound hard...? 631 [Perdita Stevens, Perdita.Stevens@dcs.ed.ac.uk, Mar 14 2002] 632 ===> It's not trivial (involves some subtle stuff about our RPC 633 implementation and the single-thread nature of the GUI), but might 634 not be impossible either. 635 636 "Quit" during synchronization should abort all current operations (so 637 that temporary files are deleted) before exiting. 638 ===> Again, requires some careful thinking about how this would work 639 with the RPC layer. 640 641 It would be nice to have a command in the GUI that would allow a single 642 path within the replica to be selected from a file dialog and 643 synchronized. 644 645 [From Manuel Serrano] Would be nice to put the arrows in different 646 directions in different colors, so that, e.g., you could quickly scan the 647 list of changes and make sure that they are all in the same direction 648 ===> We tried this, but we couldn't find color combinations that did not 649 seem confusing. (Two different shades of green? Three? ...) If we 650 really want this, probably the best is to put in some preferences for the 651 user to control the colors of all the arrows individually. 652 653 Text mode user interface should be brought up to date with graphical 654 interface (it should prompt for profile creation, root 655 entry, etc.; command characters should be the same; ...) 656 657 Since the manual is pretty big, it would be nice if the on-line version 658 were accessible through cascading menus, allowing direct access to 659 individual subsections. It would also be nice if it were formatted a 660 bit more attractively, using proportional-width fonts, etc. (Does GTK 661 have something like an RTF widget?) 662 663 If I have a change I look at the detail window. It would be nice to be 664 able to click on one of the lines there instead of pressing one of <- 665 or ->. For one thing in the detail window the relative position of the 666 two files is up and down and translating that to <- or -> is somewhat 667 unintuitive. 668 669 Also, it would be nice to highlight in the detailed window the 670 elements that have changed. 671 672 The UI window should display the current roots somewhere. 673 674 There should be a -geometry command-line interface, following the usual X 675 conventions. 676 677 put in a command-line option that makes fatal errors exit right away 678 without displaying anything in the graphical UI (for debugging) 679 680 Use the CTree widget to display the list of files 681 Add the ability to close and open directories in the UI. 682 683 it would be nice to give a visual indication of which files are 684 particularly big, so that the user can tell where the transfer 685 operations may get slowed down. Maybe a "size bar" showing the log 686 of the size (perhaps also color coded). 687 ===> less urgent now because we can re-sort the update items by size 688 689 Would it be hard to allow long-running transfers to be aborted? 690 For instance, the key "/" aborts the transmission of the selected file 691 OR: 692 Allow the user to terminate individual operations by clicking a 693 "cancel" button. (This is not completely straightforward because 694 the whole program is single-threaded. But it should be possible for 695 the low-level transport code in remote.ml to realize that the 696 operation has been aborted, clean up, and raise an exception.) 697 698 It would be nice if the initial 'usage' message were not so long. Maybe 699 we could split options into 'novice' and 'expert' ones, and only print 700 the novice ones (with an indication how to obtain the full expert 701 printout). 702 703 > Show diff should behave as an emacs view-mode buffer and quit on a single 704 > 'q' in the window, or better quit even without focus be sent to the diff 705 > window... 706 The UI for the diff functionality needs some polishing. (Also, it should 707 be merged with the new "merge" functionality.) 708 709 would be nice to be able to "Proceed" just the selected line 710 711 might be nice if the GUI would beep when finished syncing (needs to be 712 switch-selectable and off by default, naturally). Is this easy with 713 LablGTK? 714 715 716 * TIDYING 717 * ======= 718 719 * Go through the sources and make all fatal and transient error messages 720 as informative as possible 721 722 More documentation (especially in the interface files) is always nice. 723 In particular, there isn't enough documentation of the big picture. 724 It isn't clear how to fit together archives, servers, paths, roots, 725 update detection, reconciliation, conflict resolution, or the user 726 interface... 727 728 Ocamlexc v1.0, the uncaught exceptions analyzer for Objective Caml is now 729 available from Pessaux's home page. It would be fun to run it over the 730 Unison sources and see if it reveals any problems. 731 732 733 * LARGER EXTENSIONS 734 * ================= 735 736 Fast update checking would be cool... Some resources: 737 FAM (used in Enlightenment) 738 dnotify (linux 2.4) 739 BSD kqueue 740 the "VFS stacking layer" implemented by a guy at Columbia 741 742 [From JMS] 743 Some update detection speed improvement suggestions: 744 - Read the FFS (Fast Filesystem) paper for hints 745 - change the working directory instead of using absolute paths; this 746 avoids calls to the evil iname(?) facility in the kernel 747 - work breadth-first instead of depth first, to keep things in the 748 kernel cache 749 750 Rewrite recon.ml in a more modular way. Probably, have for each property 751 a function taking the previous file state and the state on each 752 replicas, and returning in what the synchronization operation should be 753 (nothing, left, right, conflict); a combinator then merge the results. 754 755 How about a facility so that you can specify more than one pair of 756 file systems for a single invocation of Unison? This would be like 757 calling Unison multiple times, except that it would ask all the 758 questions at once. Better yet, we could actually deal with the 759 multi-replica case. (The latter is pretty hard.) 760 761 What about invoking some user-specified operation on each file as it 762 is transferred? Or in each directory where things have changed? 763 (This will require some careful design work.) 764 765 Consider using other authentication services (e.g. Kerberos) instead 766 of / in addition to ssh. 767 768 What happens when we synchronize, then decide to ignore some existing file 769 What happens to the entry in the archive? If mirroring, it may be 770 large, we probably want to delete it from the archive. 771 772 File level synchronization (bookmarks, mailboxes) 773 774 It might be nice to implement an (optional) safety check that detects 775 aliasing within a replica due to followed links (or hard links) and 776 complains if it finds any. This should not be *too* expensive, since 777 we already know all the inode numbers. (Even if it *is* expensive, it 778 might be useful to allow users to do this occasionally, if they are 779 paranoid.) 780 781 Local Variables: 782 mode: outline 783 End: