I'd very much like to get a stable 2.5 release out so that people can upgrade their production machines with confidence and so that distributors can freeze it. I know some people are still running 2.4.6 (+backports) for understandable reasons, but it would be good to give them the option to upgrade and avoid the hang bug. After this we can perhaps move on to 2.6 and be a bit more liberal in accepting patches. I think there is some scope for making the file_list and hardlink handling much faster, but I don't want to do that in a stable series. So: Has anybody tried 2.5.5? Did it work well? Are there any other patches you think really need to go into a 2.5.6 before we proceed? -- Martin
Martin Pool wrote:> Has anybody tried 2.5.5? Did it work well?I ran it last night on about 400 trees. It seemed to timeout improperly. I'll have more data on this tomorrow. Timeout was set at 1000 and it seemed to timeout more than I've seen before (about 50 of the trees reported timeouts). Of course it could have been a very bad network night. Do I need to have 2.5.5 on both ends of the rsync (via ssh) to provide useful test results? I've been trying different versions of rsync on the source side, but I've been using a 2.4.6+patches on the dest end of the rsyncs. I think I'm almost ready to upgrade all the dests. Thanks for the rsync 'roadmap'. I think it is a good plan. eric
On 2 Apr 2002, Eric Whiting <ewhiting@amis.com> wrote:> Do I need to have 2.5.5 on both ends of the rsync (via ssh) to provide > useful test results?Results for both cases are useful, because we want to preserve backward compatibility. For example, if rsync 2.5.5 - 2.4.6 hangs, then I would be inclined to write that off as being caused by the 2.4 bug. But if that combination produced a corrupt file, then we certainly ought to investigate. -- Martin
On Wed, Apr 03, 2002 at 10:14:50AM +1000, Martin Pool wrote:> Are there any other patches you think really need to go into a 2.5.6 > before we proceed?The attached patch is important for "out of the box" compilation on Tru64 UNIX. The FreeBSD issue has been resolved. -- albert chin (china@thewrittenword.com) -- snip snip --- configure.in.orig Tue Apr 2 17:18:51 2002 +++ configure.in Tue Apr 2 17:19:41 2002 @@ -326,7 +326,19 @@ AC_CHECK_FUNCS(inet_ntop, , AC_LIBOBJ(lib/inet_ntop)) AC_CHECK_FUNCS(inet_pton, , AC_LIBOBJ(lib/inet_pton)) -AC_CHECK_FUNCS(getaddrinfo, , AC_LIBOBJ(lib/getaddrinfo)) +# Tru64 UNIX has getaddrinfo() but has it renamed in libc as +# something else so we must include <netdb.h> to get the +# redefinition. +AC_CHECK_FUNCS(getaddrinfo, , + [AC_MSG_CHECKING([for getaddrinfo by including <netdb.h>]) + AC_TRY_LINK([#include <sys/types.h> + #include <sys/socket.h> + #include <netdb.h>],[getaddrinfo(NULL, NULL, NULL, NULL);], + [AC_MSG_RESULT([yes]) + AC_DEFINE(HAVE_GETADDRINFO, 1, + [Define if you have the `getaddrinfo' function.])], + [AC_MSG_RESULT([no]) + AC_LIBOBJ(lib/getaddrinfo)])]) AC_CHECK_FUNCS(getnameinfo, , AC_LIBOBJ(lib/getnameinfo)) AC_CHECK_MEMBER([struct sockaddr.sa_len],