why are these files being transfered

[Harry Putnam]

Wayne Davison <wayned at samba.org> writes:

> On Sat, May 31, 2003 at 09:24:19AM -0700, Harry Putnam wrote:
>> But it seem cvs then sees them as modified.
>
> "Them" who?  You said you're transferring the files from the cvs checkout
> area to a buffer area.  Are you transferring them back again?

Them ... files in base.t.
No its the other way round.  And only one direction


OK, let me try to be more clear.  I thought this; from my original
post was good:

> The setup employs a bufffer where changes are made then moved to a
> checked out module from cvs repository and finally any cvs actions
>  necessary are done.

Since my test used a directory named cvs_buf.t  I thought it would be
clear it was the buffer area mentioned above.

So here is what I have in better detail:

TARGET of rsync command:
./base.t       <== actual checked out cvs module

SOURCE of rsync command
./cvs_buf.t    <== an area that is an approximate mirror of cvs files
                in ./base.t  
                Changes happen  here but most (nearly all) files are
                identical to their cousins in `base.t'. (except
                possibly timestamp
                        
                The idea is to do actual modificatons edit of files
                etc in ./cvs_buf.t  Then rsync cvs_buf.t to base.t

base.t contains the `CVS' directories since it is a checked out module.
All cvs commands will be done in ./base.t so that will take care of
the `CVS' directorires.  They are not involved in the rsync action.

Harry wrote:
>> Not sure I see the point of any modification, time stamp or whatever
>> if the files are the same.
[...]

Wayne answered:
> But, how do you know they're the same?  Rsync certainly doesn't (though,
> if you use my suggested -c option, it would determine that for itself).
[...]

Well the posted results of the diff commands found no difference
however rsync transfres or modifies the file in target anyway.

> rsync transfer (unless you use -c).  In the case of having identical
> files with different timestamps, rsync will transfer just the checksum
> data to determine that the files are indeed identical, and move into
> place a file with an identical timestamp (which looks just like the
> files are being transferred, but no actual file-data gets sent).

Looks like the -c flag is what I need alright.  But I still can't
understand why rsync would modifie a file where only the time stamp
is different. As you say it `moves into place a file with identical
timestamp.  But no data is transfered.  However cvs tools do think
they are modified.

Please observe this series of tests that display what is confusing me.

First a fresh `cvs co' of module base.t
cvs co base.t
[...] snipped output
We now have ./base.t

Again ./cvs_buf.t  Is  a tree of files that is a replical of ./base.t
However timestamps may be different.

  diff base.t cvs_buf.t
  Only in base.t: CVS
  Common subdirectories: base.t/common and cvs_buf.t/common
  Common subdirectories: base.t/lgate and cvs_buf.t/lgate
  Common subdirectories: base.t/obsd and cvs_buf.t/obsd
  Common subdirectories: base.t/reader and cvs_buf.t/reader
  Common subdirectories: base.t/sol and cvs_buf.t/sol

diff finds no difference except the presence CVS in base.t

Now diffing a specific file:

  diff  base.t/reader/etc/fstab cvs_buf.t/reader/etc/fstab
  Again no difference is found.

Now we run the rsync command:
(not using -c here)

 rsync -avvzC  cvs_buf.t/ base.t 2>&1| tee  /root/cvs_buf.test
  (note the -C is being used for its other propertied not to ignore
  CVS since there are no CVS dir in cvs_buf.t)

289 lines of output including

  reader/etc/fstab

[...] and ending
  wrote 641047 bytes  read 5560 bytes  431071.33 bytes/sec
  total size is 1738494  speedup is 2.69

Now lets see what cvs thinks of it:
  cd base.t
  cvs commit
  Gives me a vi buffer where every last file is listed as needing
  commit.

So apparently, at least in the eyes of cvs, every last file has been
changed.  Since files were the same to start with, this seems wrong.

I do see where -c will cure it, but I'm asking why does rsync do that
when the files are the same?

> The question should be, how are things getting out-of-whack between the
> two areas?  You should be transferring the data with -a,

All my posted rsync commands used the -a flag.

>  and then it
> should just work.  It's not clear what you're trying to do, but I assume
> there's a flaw in your use of rsync.  Either that, or you're not aware
> that 2 different CVS checkouts of the same CVS module will have
> radically different modification times on all the files even when they
> have identical content.

Now with a clearer picture of what I'm doing.  And if I haven't worn
out your kindness with all the included data, do you see what I'm
doing wrong?  And is it appropriate for rsync to alter files that
have nothing differnt in them?

>> I see --size-only does cure the problem.
>
> That would be an extraordinarily bad idea.  The only thing that
> --size-only should be used with are files that can't possibly change
> unless their size changes (such as log files).  Since source files can
> change and remain the same size, so this is not a solution.

Whew.. Thanks for the heads up on that... Yeah that would be a disaster.