release date for rsync 2.5.7?

[Manish Dubey]

--- jw schultz <jw at pegasys.ws> wrote:
[snip]

> > I have a patch, that i can submit for review.
> > 
> > > I'm inclined to discourage such a change.  rsync is modeled
> > > on cp and cp would fail if the destination directory is
> > > missing.  Furthermore, failing on missing directory is a
> > > valuable safety-net.  The majority of the time the
> > > destination directory doesn't exist it is because of an
> > > error.  Far better to have rsync to report "rsync: mkdir
> > > /hoem/henry/Mail: No such file or directory" than to have
> > > root or another wrong filesystem fill up on either system.
> > >
> > 
> > I understand the current design decision. However, what if
> > this behavior is triggered by a command line flag? I can
> > modify my patch to do that.
> > 
> > Also i want to test it for all possible use cases. Is there a
> > test harness or description of test cases that i can run my change
> > through (before submitting it for review)? I have already tested 
> > it for all my use cases (local, remote, file and directory syncing)
> >


So, is there a test harness or list of tests to qualify rsync as 
release worthy?
 
> > > It is very easy to force the directory to exist.  Just
> > > preceede rsync with "mkdir -p" if you know beyond doubt that
> > > the directory, as specified, needs to be created.
> > >
> > 
> > I know about mkdir -p, but its not just slapping "mkdir -p" before
> > doing rsync. I will have to make my code understand about syncing
> file
> > vs. directory (and create the parent directory in case of a file),
> so
> > i opted for rsync creating it for me.
> 
> A script should know what it is doing.  It isn't like we are
> talking about batch-files.  It doesn't take much to test a
> path to see if it is a directory or a file.
> 

Script knows what paths its syncing (and i know how to test for a
path being a file vs a dir and how to call mkdir -p), but i 
disagree with you on following things:

1. That the script should do the special case path processing for 
   files vs dirs to do a mkdir -p. As a good software design all 
   this logic and the related processing should be in one place 
   and one place only, and that to me is rsync (and guess what, it
   is already doing all that minus one minor glitch/feature)

2. Lets assume for a moment that script did mkdir, it will not be as
   easy as you are trying to make it, for the following reasons:

   - i already pointed out special handling of file vs dir processing
   - think of cases with wildcards. Now the script have to
     understand multiple arguments (in case of wildcard expansion) and
     handle that case correctly.
   - think of copying from a remote machine
   - think of copying from a remote machine with remote 
     wildcard expansion

   All the above cases make mkdir handling in script error prone,
   undesirable and if not fully thought out, even incomplete. 
   Furthermore all this could be easily achieved by making one 
   function call in the right place in rsync.


> > Thanks for time. I am just hoping to get my patch integrated for
> all
> > the good reasons of using a standard distribution.
> 
> I vote no on this one.
> 
> And I don't think it is worth adding yet another option.

Why? Whats wrong with yet another option? rsync already has more than
a pageful of options (you have to pipe rsync --help to more anyway)
what difference does adding another option make? I do not understand
your logic, criteria or basis for saying this.


> The only time it is going to be needed is in scripts and
> scripts will be able to do the foundational work.
>

See my points above.
 
> 
> -- 
> ________________________________________________________________
> 	J.W. Schultz            Pegasystems Technologies
> 	email address:		jw at pegasys.ws
> 
> 		Remember Cernan and Schmitt
> -- 
> To unsubscribe or change options:
> http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read:
http://www.catb.org/~esr/faqs/smart-questions.html


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com