Matt McCutchen writes:
First a comment: You have far more expertise than I in all the many
things that come into play in this kind of endeavor. So any opinions
I have or have posted should be taken with a large grain of salt.
> On Sat, 2009-01-17 at 14:57 -0600, Harry Putnam wrote:
>> Matt McC
On Sat, 2009-01-17 at 14:57 -0600, Harry Putnam wrote:
> Matt McCutchen writes:
> > You know, there are two-way synchronization tools such as unison
> > ( http://www.cis.upenn.edu/~bcpierce/unison/ ) that are designed for
> > this situation and would make your job much easier.
>
> I was experimen
Matt McCutchen writes:
>> And then try to sort through the output .. maybe run it in reverse and
>> sort through that output before making a final determination.
>
> You know, there are two-way synchronization tools such as unison
> ( http://www.cis.upenn.edu/~bcpierce/unison/ ) that are designe
On Sat, 2009-01-17 at 11:08 -0600, Harry Putnam wrote:
> I keep a checked out module from cvs at /usr/local/common/base, that
> contains the checked in versions of files in /cvsb
>
> Periodically I run rsync -blah /cvsb/ /usr/local/common/base
>
> Over writing the old cvs copies with new stuff.
Matt McCutchen writes:
> I think Harry's complaint is about the existence of the directories, not
> the nonexistence of the files.
Not much of a complaint really. I was just a bit puzzled at first.
> I believe it's by design that rsync creates a directory (call it D) in
> the destination even
On Fri, 2009-01-16 at 18:04 -0800, Wayne Davison wrote:
> On Thu, Jan 15, 2009 at 06:11:36PM -0600, Harry Putnam wrote:
> > In other words the full directory structure minus any plain files.
>
> Right, that's what compare-dest does. It only copies changed files,
> omitting all files that haven't
On Thu, Jan 15, 2009 at 06:11:36PM -0600, Harry Putnam wrote:
> In other words the full directory structure minus any plain files.
Right, that's what compare-dest does. It only copies changed files,
omitting all files that haven't changed between the source and the
alternate destination. If you
Matt McCutchen writes:
[...]
>> d1a is carbon copy of d1 but still every last file in d1 is copied to
>> d2.
>
> Two paragraphs later in the man page:
>
> "If DIR is a relative path, it is relative to the destination
> directory."
>
> So you should use:
>
> rsync -avv --compare-dest="../d1a" d
Harry Putnam wrote:
I must be seriously misunderstanding the man page coverage of
--compre-dest. My take was that if a file in compare-dest=dir
matches a file in SOURCE/ then it won't be transferred to DEST/.
I tried this test. (d1 has single files and 2 subdir with files)
cp -a d1 d1a
On Thu, 2009-01-15 at 16:54 -0600, Harry Putnam wrote:
> I tried this test. (d1 has single files and 2 subdir with files)
>
>cp -a d1 d1a
>
>mkdir d2
>
> rsync -avv --compare-dest="./d1a" d1/ d2/
>
> d1a is carbon copy of d1 but still every last file in d1 is copied to
> d2.
Two parag
I must be seriously misunderstanding the man page coverage of
--compre-dest. My take was that if a file in compare-dest=dir
matches a file in SOURCE/ then it won't be transferred to DEST/.
I tried this test. (d1 has single files and 2 subdir with files)
cp -a d1 d1a
mkdir d2
rsync -avv
11 matches
Mail list logo
