So what are you proposing?<br>
<br><br><div><span class="gmail_quote">On 6/6/05, <b class="gmail_sendername">Benjamin Pierce</b> <<a href="mailto:bcpierce@cis.upenn.edu">bcpierce@cis.upenn.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> > We're in the middle of some reimplementation work on the merge<br>> > functionality, and as part of this we're considering simplifying and<br>> > rationalizing the backup functionality.<br>> > At the moment, Unison provides two different preferences for controlling
<br>> > backups: "backup", which keeps backup copies in the same directory as the<br>> > current version of the file, and "backups", which maintains a centralized<br>> > tree of backup files under the .unison directory.
<br>><br>> from my memory (and a quick look into the manual confirms it) it is exactly<br>> the opposite:<br>> backup/backupnot/backupdir control the centralised backup<br><br>You're right: what I said was exactly backwards.
<br><br>Thanks,<br><br> - Benjamin<br><br>_______________________________________________<br>Unison-hackers mailing list<br><a href="mailto:Unison-hackers@lists.seas.upenn.edu">Unison-hackers@lists.seas.upenn.edu</a><br>
<a href="http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers">http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers</a><br></blockquote></div><br><br>