--compare-dest; I'm missing the boat

[Harry Putnam]

Matt McCutchen <matt at mattmccutchen.net> 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 if D is matched in a compare-dest directory.  If
> rsync skipped the creation of D but later found out that a file inside
> needed to be transferred, rsync would have to go back and and create D,
> looking up the correct attributes and handling itemization and the
> possibility of failure.  It would be possible to implement this, but I
> don't care to do it; rsync is convoluted enough as it is.

Pardon a -vv reply:

I see the reasonableness of the design and for my usage it is actually
an asset.  I'm testing to see which side is newer or more complete
before overwriting one with the other.  So the final target will be either
d1 or nearly_a_mirror in the schema below:

rsync -aCvv --compare-dest="/nearly_a_mirror/"
   /d1/ /d2/

Where d2 is a freshly created empty directory.

I've been using what may be a ridiculous technique with cvs but it has
been working for me for a few yrs now.

I keep a top level directory /cvsb (the b is for buffer)
That contains the hard copy of many of my system files (from several
hosts).

Then on the hosts filesystems... these files are symlinked into the
positions the OS expects to find them.  The idea being that editing as
needed is really editing the hardcopy in /cvsb.

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.  Then do the cvs
chores on the new files.

I find having that buffer in there prevents problems that arise if
I tried to do this directly in a module checked out from cvs.

I'm just stumbling around here for a good method to use once in a
while when I've forgotten if the cvs module has gotten ahead of the buffer
by cvs checkins  from remote hosts..

Using rsync's -n (dry run) flag is another way like:

  rsync -naCvv  /cvsb/ /[...]/base/

And then try to sort through the output .. maybe run it in reverse and
sort through  that output before making a final determination.

I'm finding that --compare-dest is much easier on the eyes and takes a
lot less time.  Even if run in both directions to get a real
picture. Also considerably less likely to cause an `ooops' where I've
overwritten something... I shouldn't have.

I find that running rysnc with the compare-dest and an empty
directory 
  rsync -avvC --compare-dest=([..]/base) /cvsb/ /emptydir/
  
Followed by:

    find /emptydir/ -type f

will tell the story in that I will recognize certain files and know
from that which way to run the sync.

So cutting to the chase here... I'm a happy camper.  Thanks for the
really handy tool.  convoluted, somewhat... but so versatile,,