[Unison-hackers] Proposed mode for unison: "Salvage"

[Benjamin Pierce]

Ah, that might not be so hard, then.  Maybe just a matter of extending  
the function Recon.overrideReconcilerChoices, using the information  
from the Xferhint module to see which files are duplicates.  One  
slight complexity I can see now is that you'd need to check this  
locally, on the appropriate host, not just on the client.  But anyway,  
this should get you started.

     - B


On Jan 5, 2010, at 12:08 PM, Ryan Newton wrote:

>> This would take some hacking - in particular, I'm not sure I see how
>> the user interface should work (especially the graphical one).
>
> Perhaps there was something I've missed... but I was thinking that no
> significant UI change is needed.  Rather, the effect is mainly on the
> scan phase (apologies if I've forgotten the correct unison terminology
> -- update detection phase?).
>
> The effect of (1) and (2) on the user-visible interface should be only
> to apply a filter over the usual "<-" entries that are presented.
> That is, the changes presented would be a subset of the changes
> presented if running without -salvage  (namely, files duplicated in
> other locations are suppressed, and changes from new->old are
> suppressed).
>
> I was hoping this could be implemented by leaving the whole "backend"
> the same and literally filtering the changset.
>
> If anyone else feels they need this functionality let me know.  I
> could hack on it
> but would love to partner with someone who knows the code better.
>
> -Ryan
>
> On Tue, Jan 5, 2010 at 11:49 AM, Benjamin Pierce <bcpierce at cis.upenn.edu 
> > wrote:
>> This would take some hacking - in particular, I'm not sure I see how
>> the user interface should work (especially the graphical one).  But I
>> agree that unison would be a decent base for building such a tool.
>>
>>        - Benjamin
>>
>> On Jan 5, 2010, at 9:54 AM, Ryan Newton <newton at mit.edu> wrote:
>>
>>> The biggest complaint I hear from friends and family about unison is
>>> the ease of duplicating files.  This happens most often when running
>>> unison without saved archives (e.g. because things get moved around,
>>> mixed up, moved to new machines, etc).
>>>
>>> A typical scenario that is difficult to handle with unison is that  
>>> you
>>> come across an old copy of folder X that *might* contain something
>>> that you forgot to extract or move into your current, primary copy.
>>> But of course you don't know what's there and checking is manually
>>> hard.  Further, performing a simple unison is the WRONG answer,
>>> because the organization may have changed substantially, making it
>>> very hard to tell if supposedly new files in the old copy are really
>>> new or have just been moved (duplication danger).
>>>
>>> In this case it would be very useful to run unison in mode where:
>>>
>>>  (1) only copies from old->new are considered.  The goal is not two
>>> identical archives, but to retrieve things from the old copy.
>>>  (2) only files which do not exist ANYWHERE in the new archive are
>>> considered, the new archive is just a flat set of files for the
>>> purpose of this check.
>>>
>>> Secondary questions include where to put the new files (presumably  
>>> the
>>> same path as in the old archive) and what to do with
>>> conflicts/collisions resulting from, for example, modified files
>>> (presumably they're treated in the normal unison way).
>>>
>>> The interface could perhaps be a "-salvage X" flag, where X is one  
>>> of
>>> the roots (just like -force).
>>>
>>> Best,
>>> -Ryan
>>>
>>> P.S. I actually wrote a separate tool at some point (in ocaml) that
>>> could accomplish the above which I could provide to the curious.   
>>> Its
>>> goal was to replace all the files in a folder X, that exist in a
>>> folder Y, with symlinks into folder Y.  One could run this on the  
>>> old
>>> archive and then use "find" to see all the files that were not  
>>> turned
>>> to symlinks.  However, I think leveraging unison for this purpose
>>> would be much more desirable.
>>> _______________________________________________
>>> Unison-hackers mailing list
>>> Unison-hackers at lists.seas.upenn.edu
>>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at lists.seas.upenn.edu
>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>>
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>