From bcpierce at seas.upenn.edu Mon Dec 1 09:00:47 2008 From: bcpierce at seas.upenn.edu (Benjamin C. Pierce) Date: Mon, 1 Dec 2008 09:00:47 -0500 Subject: [Unison-hackers] [unison-svn] r314 - trunk/src Message-ID: <200812011400.mB1E0lqP017057@yaws.seas.upenn.edu> Author: bcpierce Date: 2008-12-01 09:00:40 -0500 (Mon, 01 Dec 2008) New Revision: 314 Modified: trunk/src/RECENTNEWS trunk/src/TODO.txt trunk/src/mkProjectInfo.ml Log: * Bumped version number to reflect newly added preference Modified: trunk/src/RECENTNEWS =================================================================== --- trunk/src/RECENTNEWS 2008-12-01 03:57:57 UTC (rev 313) +++ trunk/src/RECENTNEWS 2008-12-01 14:00:40 UTC (rev 314) @@ -1,3 +1,11 @@ +CHANGES FROM VERSION 2.32.0 + +* Bumped version number to reflect newly added preference + + + + +------------------------------- CHANGES FROM VERSION 2.31.11 * Fixed a bug that was causing new files to be created with Modified: trunk/src/TODO.txt =================================================================== --- trunk/src/TODO.txt 2008-12-01 03:57:57 UTC (rev 313) +++ trunk/src/TODO.txt 2008-12-01 14:00:40 UTC (rev 314) @@ -698,7 +698,28 @@ http://www-2.cs.cmu.edu/~jcl/programs/sync_file.tar.gz Make sure you pay attention to the compile line as it is important. +[Ivo Welch] I would do a quick test of case sensitivity in the program +itself at the time you do a first prf sync, so that the user does not have +to bother with it. Just write two files on each end which differ in case, +and see if there is overwriting. Then do the smart thing. The long-named +file in the .unison directory should keep this information thereafter. +(BCP: Implementing this is more difficult than it might seem. E.g., +whenever a symlink is followed we might need to go through the same +exercise. And then we'd need to be able to deal with replicas that are not +all one way or the other...) +[Ivo Welch] I would give some examples in the man page of what an xxx +specification is. + +[Ivo Welch] I would allow '--' switches, in addition to the '-' switch spec. + +[Ivo Welch] On OSX, create a link from ~/Library/Application Support/Unison +to .unison, just for ease of finding it. It took me a long time to find my +.prf files. + +[Ivo Welch] the OSX GUI front end should be clear which side (left or right) +the local host and which side the remote host is. + * USER INTERFACE * ============== Modified: trunk/src/mkProjectInfo.ml =================================================================== --- trunk/src/mkProjectInfo.ml 2008-12-01 03:57:57 UTC (rev 313) +++ trunk/src/mkProjectInfo.ml 2008-12-01 14:00:40 UTC (rev 314) @@ -5,8 +5,8 @@ let projectName = "unison" let majorVersion = 2 -let minorVersion = 31 -let pointVersionOrigin = 301 (* Revision that corresponds to point version 0 *) +let minorVersion = 32 +let pointVersionOrigin = 313 (* Revision that corresponds to point version 0 *) (* Documentation: This is a program to construct a version of the form Major.Minor.Point, @@ -98,3 +98,4 @@ + From Jerome.Vouillon at pps.jussieu.fr Fri Dec 5 11:50:15 2008 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Fri, 5 Dec 2008 17:50:15 +0100 Subject: [Unison-hackers] Problem with fractional mtime? ("destination updated during synchronization") In-Reply-To: <39071660-FFFA-4852-A14D-3F57AE75D416@cis.upenn.edu> References: <200810292158.13947.hans_meine@gmx.net> <200811230147.49766.hans_meine@gmx.net> <200811231342.44731.hans_meine@gmx.net> <39071660-FFFA-4852-A14D-3F57AE75D416@cis.upenn.edu> Message-ID: <20081205165014.GA4637@pps.jussieu.fr> On Sun, Nov 23, 2008 at 08:44:54AM -0500, Benjamin Pierce wrote: > There is some rather tricky code in props.ml (in the sub-module Time) > that compares file modtimes while trying to take into account some > possible reasons why unchanged files may appear to have different > modtimes (e.g., daylight savings time, or one filesystem being FAT, > which can only store modtimes with a resolution of two seconds). If > the problem you're seeing is really with fractional modtimes, it may > be possible to fix it by changing something here... The fix should be the following: - Use function similar_correct, which ignore one-second differences, instead of function similar in module Time in file props.ml - Change the definition of function hash from let hash t h = Uutil.hash2 (match t with Synced f -> Hashtbl.hash (moduloOneHour (approximate f)) | NotSynced _ -> 0) h to let hash t h = h (Two similar times should have the same hash; if we ignore one-second differences, this mean that all times should have the same hash.) - Increment the variable archiveFormat in file update.ml (Indeed, the archive invariant is changed.) This is a change that I have wanted to perform for some time, but never did because of the archive format change. -- Jerome From web.kiddo at free.fr Wed Dec 10 21:40:54 2008 From: web.kiddo at free.fr (Jeff) Date: Wed, 10 Dec 2008 21:40:54 -0500 Subject: [Unison-hackers] usability, translations Message-ID: <1228963254.8989.15.camel@dell-desktop.example.com> Hello folks, I am a UI designer and translator. I would like to know: - Can unison be translated? If so, I'd gladly provide a French translation, given there is a .pot file or example .po files - Are you interested in me doing a complete usability review of the GTK GUI to make it prettier, easier to use, and better integrated in environments such as GNOME? - If yes, are there good chances that the suggestions will get implemented (if you agree with the ideas, of course)? As I said, I'm no programmer and would not be able to provide a patch (unless your GUI is made with glade, which I doubt). - Do you have a bug tracker? I couldn't find one, and, I have difficulty imagining how projects can manage bug reports/feature requests/tasks without one. I use unison every day to sync my two computers since I lost hope in the iFolder project. And, except some missing UI polish, I dare say that unison is a pretty good piece of software. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20081210/03ce8435/attachment.htm From bcpierce at cis.upenn.edu Thu Dec 11 11:02:04 2008 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Thu, 11 Dec 2008 11:02:04 -0500 Subject: [Unison-hackers] usability, translations In-Reply-To: <1228963254.8989.15.camel@dell-desktop.example.com> References: <1228963254.8989.15.camel@dell-desktop.example.com> Message-ID: <226B0732-1634-4EA8-94D3-FA1C3E9F2EE3@cis.upenn.edu> Hi Jeff, I'm afraid there's no one actively working on the GTK GUI at the moment. Best, - Benjamin On Dec 10, 2008, at 9:40 PM, Jeff wrote: > Hello folks, > > I am a UI designer and translator. I would like to know: > - Can unison be translated? If so, I'd gladly provide a French > translation, given there is a .pot file or example .po files > - Are you interested in me doing a complete usability review of the > GTK GUI to make it prettier, easier to use, and better integrated in > environments such as GNOME? > - If yes, are there good chances that the suggestions will get > implemented (if you agree with the ideas, of course)? As I said, I'm > no programmer and would not be able to provide a patch (unless your > GUI is made with glade, which I doubt). > - Do you have a bug tracker? I couldn't find one, and, I have > difficulty imagining how projects can manage bug reports/feature > requests/tasks without one. > > I use unison every day to sync my two computers since I lost hope in > the iFolder project. And, except some missing UI polish, I dare say > that unison is a pretty good piece of software. Thanks! > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From alan.schmitt at polytechnique.org Mon Dec 15 10:16:08 2008 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Mon, 15 Dec 2008 16:16:08 +0100 Subject: [Unison-hackers] Screenshot of GTK interface? Message-ID: Hello, I'm going to give a talk next Wednesday on Unison, and I'd like to show screenshots of the different interfaces. Unfortunately running the GTK version is quite tricky for me (I would need to install many things), so I was wondering if someone could take a screenshot of this interface and send it to me. Thanks a lot, Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20081215/7a8d9e1f/PGP.sig From Jerome.Vouillon at pps.jussieu.fr Tue Dec 16 11:15:12 2008 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Tue, 16 Dec 2008 17:15:12 +0100 Subject: [Unison-hackers] Screenshot of GTK interface? In-Reply-To: References: Message-ID: <20081216161512.GA24930@pps.jussieu.fr> Hi Alan, > I'm going to give a talk next Wednesday on Unison, and I'd like to show > screenshots of the different interfaces. Unfortunately running the GTK > version is quite tricky for me (I would need to install many things), so > I was wondering if someone could take a screenshot of this interface and > send it to me. Here is a screenshot. -- Jerome -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture-Unison.png Type: image/png Size: 44955 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20081216/1caed023/Capture-Unison-0001.png From duane.mckinney at gmail.com Sat Dec 27 10:27:58 2008 From: duane.mckinney at gmail.com (Duane McKinney) Date: Sat, 27 Dec 2008 15:27:58 +0000 (UTC) Subject: [Unison-hackers] Sneaker Net or Incremental Backup Message-ID: I searched, but came up empty. Can this be done. I sync two offices using unison. 1) (Optional)I would like to be able to set a preference that says, don't try to sync a file if it would require X bytes transferred 2) Get a list of changed files from a root. That way I can copy the files to a removable drive and sync them when I get to the other office. Here is my reasoning. Most of the time, root changes are very small, a few MB. But Let's say that I download a new CENTOS release and place it on the file server. This may be a poor example, because I could retrieve it over the internet again, but just bear with me. I would like for unison, to instead of trying to sync this file over the network to skip it. The I would like to be able to say once a week, run a job, that would take the differences in the root and sent them to a USB drive. I can then carry this drive to location 2, and update the root there. Then from my understanding, the network sync would detect that both roots are identical. That way, our bandwidth isn't being eaten up for hours/days, trying to perform a sync that will most likely fail because it will take so long. Also, this would be more useful, than synchronizing the whole root to a usb drive, because, the total of the data that I am synchronizing is > 1TB. I would not mind moving a few GB (<100) via USB. I am trying to avoid needing either, a lot of time, or a bunch of USB drives (one for each root). I have not yet looked at the source, but I would assume that most of the items required for this feature are already in place. Is it feasible? Is there already a way? From bcpierce at cis.upenn.edu Sat Dec 27 12:13:10 2008 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Sat, 27 Dec 2008 12:13:10 -0500 Subject: [Unison-hackers] Sneaker Net or Incremental Backup In-Reply-To: References: Message-ID: Both of these features would be easy to implement using information that Unison already has available. If you want to give it a try, I can tell you where to start. (I'd be reluctant, though, to add this code to the main sources -- Unison arguably has too many flags and switches already!) Best, - Benjamin On Dec 27, 2008, at 10:27 AM, Duane McKinney wrote: > I searched, but came up empty. Can this be done. > I sync two offices using unison. > 1) (Optional)I would like to be able to set a preference that says, > don't try to > sync a file if it would require X bytes transferred > 2) Get a list of changed files from a root. That way I can copy the > files to a > removable drive and sync them when I get to the other office. > > Here is my reasoning. Most of the time, root changes are very > small, a few MB. > But Let's say that I download a new CENTOS release and place it on > the file > server. This may be a poor example, because I could retrieve it > over the > internet again, but just bear with me. I would like for unison, to > instead of > trying to sync this file over the network to skip it. The I would > like to be > able to say once a week, run a job, that would take the differences > in the root > and sent them to a USB drive. I can then carry this drive to > location 2, and > update the root there. Then from my understanding, the network > sync would > detect that both roots are identical. > > That way, our bandwidth isn't being eaten up for hours/days, trying > to perform a > sync that will most likely fail because it will take so long. > > Also, this would be more useful, than synchronizing the whole root > to a usb > drive, because, the total of the data that I am synchronizing is > > 1TB. I would > not mind moving a few GB (<100) via USB. I am trying to avoid > needing either, a > lot of time, or a bunch of USB drives (one for each root). > > I have not yet looked at the source, but I would assume that most of > the items > required for this feature are already in place. Is it feasible? Is > there > already a way? > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From duane.mckinney at gmail.com Tue Dec 30 07:04:59 2008 From: duane.mckinney at gmail.com (Duane McKinney) Date: Tue, 30 Dec 2008 04:04:59 -0800 Subject: [Unison-hackers] Sneaker Net or Incremental Backup In-Reply-To: References: Message-ID: <495A0E6B.2040509@gmail.com> What about a flag that tells it to instead of executing the copies, just prints out a list of the files that would be copied? A proper name is escaping me at the moment, but it is a common option on programs. Benjamin Pierce wrote: > Both of these features would be easy to implement using information > that Unison already has available. If you want to give it a try, I > can tell you where to start. (I'd be reluctant, though, to add this > code to the main sources -- Unison arguably has too many flags and > switches already!) > > Best, > > - Benjamin > > On Dec 27, 2008, at 10:27 AM, Duane McKinney wrote: > >> I searched, but came up empty. Can this be done. >> I sync two offices using unison. >> 1) (Optional)I would like to be able to set a preference that says, >> don't try to >> sync a file if it would require X bytes transferred >> 2) Get a list of changed files from a root. That way I can copy the >> files to a >> removable drive and sync them when I get to the other office. >> >> Here is my reasoning. Most of the time, root changes are very >> small, a few MB. >> But Let's say that I download a new CENTOS release and place it on >> the file >> server. This may be a poor example, because I could retrieve it >> over the >> internet again, but just bear with me. I would like for unison, to >> instead of >> trying to sync this file over the network to skip it. The I would >> like to be >> able to say once a week, run a job, that would take the differences >> in the root >> and sent them to a USB drive. I can then carry this drive to >> location 2, and >> update the root there. Then from my understanding, the network >> sync would >> detect that both roots are identical. >> >> That way, our bandwidth isn't being eaten up for hours/days, trying >> to perform a >> sync that will most likely fail because it will take so long. >> >> Also, this would be more useful, than synchronizing the whole root >> to a usb >> drive, because, the total of the data that I am synchronizing is > >> 1TB. I would >> not mind moving a few GB (<100) via USB. I am trying to avoid >> needing either, a >> lot of time, or a bunch of USB drives (one for each root). >> >> I have not yet looked at the source, but I would assume that most of >> the items >> required for this feature are already in place. Is it feasible? Is >> there >> already a way? >> >> _______________________________________________ >> Unison-hackers mailing list >> Unison-hackers at lists.seas.upenn.edu >> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From duane.mckinney at gmail.com Tue Dec 30 07:22:07 2008 From: duane.mckinney at gmail.com (Duane McKinney) Date: Tue, 30 Dec 2008 04:22:07 -0800 Subject: [Unison-hackers] Sneaker Net or Incremental Backup In-Reply-To: <495A0E6B.2040509@gmail.com> References: <495A0E6B.2040509@gmail.com> Message-ID: <495A126F.40205@gmail.com> Or from Version 2.31.4 copyprog xxx A string giving the name of an external program that can be used to copy large files efficiently (plus command-line switches telling it to copy files in-place). The default setting invokes rsync with appropriate options?most users should not need to change it. copyprogrest xxx A variant of copyprog that names an external program that should be used to continue the transfer of a large file that has already been partially transferred. Typically, copyprogrest will just be copyprog with one extra option (e.g., ?partial, for rsync). The default setting invokes rsync with appropriate options?most users should not need to change it. copythreshold n A number indicating above what filesize (in kilobytes) Unison should use the external copying utility specified by copyprog. Specifying 0 will cause all copies to use the external program; a negative number will prevent any files from using it. The default is -1. See the Making Unison Faster on Large Files section for more information. I guess I should have checked out the Beta Documentation 1st. I'll try messing around with using a shell script as the copyprog. I would assume that it would work just fine. My plan is to write a shell script which ignores the destination unison tells it, and instead copies it to a usb drive. I'll probably report back on this in a week or so. Currently I am running 2.27, so I have some compiling and testing to do. Duane McKinney wrote: > What about a flag that tells it to instead of executing the copies, just > prints out a list of the files that would be copied? A proper name is > escaping me at the moment, but it is a common option on programs. > > Benjamin Pierce wrote: >> Both of these features would be easy to implement using information >> that Unison already has available. If you want to give it a try, I >> can tell you where to start. (I'd be reluctant, though, to add this >> code to the main sources -- Unison arguably has too many flags and >> switches already!) >> >> Best, >> >> - Benjamin >> >> On Dec 27, 2008, at 10:27 AM, Duane McKinney wrote: >> >>> I searched, but came up empty. Can this be done. >>> I sync two offices using unison. >>> 1) (Optional)I would like to be able to set a preference that says, >>> don't try to >>> sync a file if it would require X bytes transferred >>> 2) Get a list of changed files from a root. That way I can copy the >>> files to a >>> removable drive and sync them when I get to the other office. >>> >>> Here is my reasoning. Most of the time, root changes are very >>> small, a few MB. >>> But Let's say that I download a new CENTOS release and place it on >>> the file >>> server. This may be a poor example, because I could retrieve it >>> over the >>> internet again, but just bear with me. I would like for unison, to >>> instead of >>> trying to sync this file over the network to skip it. The I would >>> like to be >>> able to say once a week, run a job, that would take the differences >>> in the root >>> and sent them to a USB drive. I can then carry this drive to >>> location 2, and >>> update the root there. Then from my understanding, the network >>> sync would >>> detect that both roots are identical. >>> >>> That way, our bandwidth isn't being eaten up for hours/days, trying >>> to perform a >>> sync that will most likely fail because it will take so long. >>> >>> Also, this would be more useful, than synchronizing the whole root >>> to a usb >>> drive, because, the total of the data that I am synchronizing is > >>> 1TB. I would >>> not mind moving a few GB (<100) via USB. I am trying to avoid >>> needing either, a >>> lot of time, or a bunch of USB drives (one for each root). >>> >>> I have not yet looked at the source, but I would assume that most of >>> the items >>> required for this feature are already in place. Is it feasible? Is >>> there >>> already a way? >>> >>> _______________________________________________ >>> Unison-hackers mailing list >>> Unison-hackers at lists.seas.upenn.edu >>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From duane.mckinney at gmail.com Tue Dec 30 07:22:07 2008 From: duane.mckinney at gmail.com (Duane McKinney) Date: Tue, 30 Dec 2008 04:22:07 -0800 Subject: [Unison-hackers] Sneaker Net or Incremental Backup In-Reply-To: <495A0E6B.2040509@gmail.com> References: <495A0E6B.2040509@gmail.com> Message-ID: <495A126F.40205@gmail.com> Or from Version 2.31.4 copyprog xxx A string giving the name of an external program that can be used to copy large files efficiently (plus command-line switches telling it to copy files in-place). The default setting invokes rsync with appropriate options?most users should not need to change it. copyprogrest xxx A variant of copyprog that names an external program that should be used to continue the transfer of a large file that has already been partially transferred. Typically, copyprogrest will just be copyprog with one extra option (e.g., ?partial, for rsync). The default setting invokes rsync with appropriate options?most users should not need to change it. copythreshold n A number indicating above what filesize (in kilobytes) Unison should use the external copying utility specified by copyprog. Specifying 0 will cause all copies to use the external program; a negative number will prevent any files from using it. The default is -1. See the Making Unison Faster on Large Files section for more information. I guess I should have checked out the Beta Documentation 1st. I'll try messing around with using a shell script as the copyprog. I would assume that it would work just fine. My plan is to write a shell script which ignores the destination unison tells it, and instead copies it to a usb drive. I'll probably report back on this in a week or so. Currently I am running 2.27, so I have some compiling and testing to do. Duane McKinney wrote: > What about a flag that tells it to instead of executing the copies, just > prints out a list of the files that would be copied? A proper name is > escaping me at the moment, but it is a common option on programs. > > Benjamin Pierce wrote: >> Both of these features would be easy to implement using information >> that Unison already has available. If you want to give it a try, I >> can tell you where to start. (I'd be reluctant, though, to add this >> code to the main sources -- Unison arguably has too many flags and >> switches already!) >> >> Best, >> >> - Benjamin >> >> On Dec 27, 2008, at 10:27 AM, Duane McKinney wrote: >> >>> I searched, but came up empty. Can this be done. >>> I sync two offices using unison. >>> 1) (Optional)I would like to be able to set a preference that says, >>> don't try to >>> sync a file if it would require X bytes transferred >>> 2) Get a list of changed files from a root. That way I can copy the >>> files to a >>> removable drive and sync them when I get to the other office. >>> >>> Here is my reasoning. Most of the time, root changes are very >>> small, a few MB. >>> But Let's say that I download a new CENTOS release and place it on >>> the file >>> server. This may be a poor example, because I could retrieve it >>> over the >>> internet again, but just bear with me. I would like for unison, to >>> instead of >>> trying to sync this file over the network to skip it. The I would >>> like to be >>> able to say once a week, run a job, that would take the differences >>> in the root >>> and sent them to a USB drive. I can then carry this drive to >>> location 2, and >>> update the root there. Then from my understanding, the network >>> sync would >>> detect that both roots are identical. >>> >>> That way, our bandwidth isn't being eaten up for hours/days, trying >>> to perform a >>> sync that will most likely fail because it will take so long. >>> >>> Also, this would be more useful, than synchronizing the whole root >>> to a usb >>> drive, because, the total of the data that I am synchronizing is > >>> 1TB. I would >>> not mind moving a few GB (<100) via USB. I am trying to avoid >>> needing either, a >>> lot of time, or a bunch of USB drives (one for each root). >>> >>> I have not yet looked at the source, but I would assume that most of >>> the items >>> required for this feature are already in place. Is it feasible? Is >>> there >>> already a way? >>> >>> _______________________________________________ >>> Unison-hackers mailing list >>> Unison-hackers at lists.seas.upenn.edu >>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From bcpierce at seas.upenn.edu Tue Dec 30 11:19:00 2008 From: bcpierce at seas.upenn.edu (bcpierce@seas.upenn.edu) Date: Tue, 30 Dec 2008 11:19:00 -0500 Subject: [Unison-hackers] Sneaker Net or Incremental Backup In-Reply-To: <495A126F.40205@gmail.com> References: <495A0E6B.2040509@gmail.com> <495A126F.40205@gmail.com> Message-ID: <20081230111900.tkbedc8r8c04so40@webmail.seas.upenn.edu> That's a nice hack -- I had no idea the new copyprog functionality could be used that way. Will be interested to hear whether it works... - Benjamin Quoting Duane McKinney : > Or from Version 2.31.4 > copyprog xxx > A string giving the name of an external program that can be used to > copy large files efficiently (plus command-line switches telling it to > copy files in-place). The default setting invokes rsync with appropriate > options?most users should not need to change it. > > copyprogrest xxx > A variant of copyprog that names an external program that should be > used to continue the transfer of a large file that has already been > partially transferred. Typically, copyprogrest will just be copyprog > with one extra option (e.g., ?partial, for rsync). The default setting > invokes rsync with appropriate options?most users should not need to > change it. > > copythreshold n > A number indicating above what filesize (in kilobytes) Unison > should use the external copying utility specified by copyprog. > Specifying 0 will cause all copies to use the external program; a > negative number will prevent any files from using it. The default is -1. > See the Making Unison Faster on Large Files section for more information. > > I guess I should have checked out the Beta Documentation 1st. I'll try > messing around with using a shell script as the copyprog. I would > assume that it would work just fine. My plan is to write a shell script > which ignores the destination unison tells it, and instead copies it to > a usb drive. > > I'll probably report back on this in a week or so. Currently I am > running 2.27, so I have some compiling and testing to do. > > Duane McKinney wrote: >> What about a flag that tells it to instead of executing the copies, just >> prints out a list of the files that would be copied? A proper name is >> escaping me at the moment, but it is a common option on programs. >> >> Benjamin Pierce wrote: >>> Both of these features would be easy to implement using information >>> that Unison already has available. If you want to give it a try, I >>> can tell you where to start. (I'd be reluctant, though, to add this >>> code to the main sources -- Unison arguably has too many flags and >>> switches already!) >>> >>> Best, >>> >>> - Benjamin >>> >>> On Dec 27, 2008, at 10:27 AM, Duane McKinney wrote: >>> >>>> I searched, but came up empty. Can this be done. >>>> I sync two offices using unison. >>>> 1) (Optional)I would like to be able to set a preference that says, >>>> don't try to >>>> sync a file if it would require X bytes transferred >>>> 2) Get a list of changed files from a root. That way I can copy the >>>> files to a >>>> removable drive and sync them when I get to the other office. >>>> >>>> Here is my reasoning. Most of the time, root changes are very >>>> small, a few MB. >>>> But Let's say that I download a new CENTOS release and place it on >>>> the file >>>> server. This may be a poor example, because I could retrieve it >>>> over the >>>> internet again, but just bear with me. I would like for unison, to >>>> instead of >>>> trying to sync this file over the network to skip it. The I would >>>> like to be >>>> able to say once a week, run a job, that would take the differences >>>> in the root >>>> and sent them to a USB drive. I can then carry this drive to >>>> location 2, and >>>> update the root there. Then from my understanding, the network >>>> sync would >>>> detect that both roots are identical. >>>> >>>> That way, our bandwidth isn't being eaten up for hours/days, trying >>>> to perform a >>>> sync that will most likely fail because it will take so long. >>>> >>>> Also, this would be more useful, than synchronizing the whole root >>>> to a usb >>>> drive, because, the total of the data that I am synchronizing is > >>>> 1TB. I would >>>> not mind moving a few GB (<100) via USB. I am trying to avoid >>>> needing either, a >>>> lot of time, or a bunch of USB drives (one for each root). >>>> >>>> I have not yet looked at the source, but I would assume that most of >>>> the items >>>> required for this feature are already in place. Is it feasible? Is >>>> there >>>> already a way? >>>> >>>> _______________________________________________ >>>> 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 > >