filelist calculation algoritm

[Wayne Davison]

On Sat, Jan 04, 2003 at 05:03:02PM -0800, jw schultz wrote:
> that would produce destloc/srcdir/....
> when you might want a copy of srcdir at destloc instead of
> in destloc.

Ah yes, I _was_ missing something.  However, I still don't think we need
to clutter rsync with two types of --file-list options.  This is already
something that people have to deal with when using the --relative option:
how to generate a file list that contains just the path information that
we need to be significant.  I think that the removal of the undesired
prefixes should happen before the list gets to rsync rather than having
rsync do it (in your example the user would just chdir into "srcdir" and
do the "find" relative to '.').

Here's an alternative to the syntax you suggested.  I was thinking that
it would be nice to just read filenames from stdin and have them be
treated the same way as command-line args.  One way to indicate this
would be to specify '-' as a name to transfer, which would tell rsync to
read filenames from stdin.  Like this:

    rsync -av --relative - destloc <input-file

What would need to change in the protocol is that the list of filename
args would need to get sent over the rsync connection rather than being
sent as part of the remote-shell+rsync command-line.  Other than that
(and the code to actually slurp the filenames from stdin) no other
changes to rsync would be needed, so it should be pretty easy to
implement.

FYI, the old rsync release that had a type of file-list functionality
was using a specialized include/exclude list.  I believe that rsync
still walked the entire directory tree on both sides, and applied the
includes using a slightly different algorithm than the default (one that
did not require parent directories to be mentioned to get down to all
the specified files).  I think that it would be nice to avoid the
directory-tree traversal, so I don't think we want to go this route.
However, this is another potential implementation method (and one that
would result in a syntax that is like what you suggested:  one that uses
a single source dir on the command-line and doesn't require the use of
the --relative option).

..wayne..