[Unison-hackers] File copying/moving optimizations

[Alan Schmitt]

On 2 nov. 05, at 23:03, Jerry Haltom wrote:

> So I notice that Unison completely re-downloads a file when it is the
> result of a copy or a move. Makes sense from a simple implementation
> point of view, but I was wondering about an alternative.
>
> When a file is seen as not existing in the replica, it makes sense  
> to me
> for the data of the file to be searched for in the replica, and copied
> to the new name if found. The original says a file with a certain MD5
> sum exists at a new location, the replicate searches for an existing
> file with that MD5 sum and copies it.
>
> Seems like this could speed up synchronization in some specific  
> cases by
> a good deal. Simply renaming a large top level directory would  
> result in
> a new directory being created in the replica and populated from the
> previous data. Much faster!
>
> Thoughts?

Well, it should already be the case. According to the manual:

xferbycopying
When this preference is set, Unison will try to avoid transferring  
file contents across the network by recognizing when a file with the  
required contents already exists in the target replica. This usually  
allows file moves to be propagated very quickly. The default value is  
true.

Alan Schmitt

-- 
The hacker: someone who figured things out and made something cool  
happen.
.O.
..O
OOO


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20051103/3bb0fd44/PGP.pgp