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

[Ryan Newton]

> 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
>