FW: Expanding the include/exclude options

[Ben Escoto]

--==_Exmh_-1315871627P
Content-Type: text/plain; charset=us-ascii

>>>>> "JP" == Jason Piterak <Jason>
>>>>> wrote the following on Thu, 28 Mar 2002 11:30:08 -0500

  JP> ...so how about something like:
 
  JP>      <call to file selection command/script>|rdiff-backup
  JP> --exclude <any additional exclusions>
  JP> dest_username@dest_host::dest_path
 
Well, one problem I see with this is that it isn't clear what the
source directory is.  For instance, suppose your file list looks like
this:

/usr/local/bin
/usr/local/doc
...

where all the files are in /usr/local.  Then you run

cat filelist | rdiff-backup --exclude <whatever> /dest_path

as you suggest.  Then it wouldn't be clear whether the source dir is
/, /usr, or /usr/local.  Should /usr/local/bin go into
/dest_path/usr/local/bin, /dest_path/local/bin, or /dest_path/bin?

    So it seems that a source path is still needed.  So the updated
command would be:

cat filelist | rdiff-backup --exclude <whatever> /usr /dest_path

but now this just looks like ordinary rdiff-backup syntax and we need
some way of telling it to use a file list on stdin.  So now:

cat filelist | rdiff-backup --include-from-filelist - --exclude
    <whatever> /usr /dest_path

but this looks a lot like the earlier syntax proposed..  (It is a bit
simpler though, in that no --exclude-all option is required.  Perhaps
then that the default will be to include all, unless the first
include/exclude option is an include, in which case --exclude-all is
the default?)

  JP>    One problem with this comes when you have issues with the
  JP> same source filenames clobbering each other at the
  JP> destination. You could add a clobber/noclobber switch.  Another
  JP> problem is wanting multiple destination
  JP> directories/locations... I would say just deal with that with
  JP> another rdiff-backup call.
 
Sorry, I don't understand this, what do you mean about clobbering?

  JP>    I think both of your criticisms are right on... It WOULD be
  JP> complicated, and probably not flexible enough...

Well, as far as I understand it, the system you suggest is a subset of
the first system suggested, so yours should also have a flexibility
problem...


--
Ben Escoto

--==_Exmh_-1315871627P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001

iD8DBQE8o9M1+owuOvknOnURAmo+AJ9ulbOqAIx033xEkxk73laC+TjIUQCeK80d
DHA1amchBSr6tTcgV6GCik4=
=14nu
-----END PGP SIGNATURE-----

--==_Exmh_-1315871627P--