[Unison-hackers] An idea for faster initial syncs

[Hans Meine]

On Thursday 22 July 2010 03:48:09 Benjamin Pierce wrote:
> * It's tempting to make this a default behavior -- i.e., to *always* use a
> dummy fingerprint whenever we encounter a new file.

Yes, that would also be more consistent.

> The cost of this is
> that, if the file happens to get touched, it will get re-fingerprinted and
> show up as having been changed even if it has not really.

That would be ugly.  I like to check all synchronized changes before 
confirming, and I hate getting "bogus" changes.  (For instance, I recently 
started using OS X, and I got sooo many changes on the mac side, leading to an 
awful lot of conflicts, until I disabled the metadata syncing.  At least, that 
seemed to be the cause.)

I think waiting is less costly for the user than thinking about why some files 
changed and whether they should be sync'ed.

> With a little
> work, maybe this could be made invisible to the user most of the time;
> we'd have to notice when we had a recon item involving a "recently dummy"
> file (i.e., where one side is a dummy and the other is not) and
> re-fingerprint the non-dummy side.

That could work.

Another idea would be to automatically fingerprint files with a dummy hash in 
the background in "spare"/idle time, i.e. while waiting for user input.  IMHO 
that would get us the best of both worlds: quick initial responses from a 
user's POV, and proper fingerprints ASAP.

The only downsides here are the increased implementation complexity and that 
the user should ideally be informed about the progress somehow (otherwise 
he/she might wonder why the HDD is working so much, or - even if the cause is 
known - when it will stop).

Have a nice day,
  Hans