Ok, so I see that we're still stuck at rsync-2.6.0 (released Jan 2004 (two years ago as of this writing)) because of mysterious problems with other versions (bug: 49933 and the related (but unanswered) bug: 90394), but what about now? It's been almost a year since anyone visibly poked at rsync, but there are newer, but "unstable", versions available in portage. Is there any plan for migrating any of those newer versions (especially >=2.6.5) into stable or are we just going to stick with 2.6.0 for all time? I'm willing to put my installation where my mouth is if I can help move this process along in any way.
*** This bug has been marked as a duplicate of 49933 ***
(In reply to comment #1) > > *** This bug has been marked as a duplicate of 49933 *** No, it's not quite a duplicate of 49933 and even if it is, simply marking it as a duplicate didn't answer my question, nor solve the bug. My point here was to bring to the forefront the fact that we're sitting on a two year old version of rsync and there doesn't seem to be any progress being made to move forward. By marking all bugs duplicates of the "RESOLVED" bug 49933, we're not getting any visibility here (out of sight and all that). If you want to mark this duplicate, that's cool, but then reopen 49933 as something we need to look at. If 49933 is truly RESOLVED, then leave this bug open. Either way, we need to make progress on this.
*** Bug 126043 has been marked as a duplicate of this bug. ***
Newer rsync versions include a lot of bugfixes and more clear error output, are there any showstoppers in them? If not I suggest we move to a more recent version, most probably that will help every Gentoo user...
(In reply to comment #4) > Newer rsync versions include a lot of bugfixes and more clear error output, are > there any showstoppers in them? If not I suggest we move to a more recent > version, most probably that will help every Gentoo user... > I agree... I work with Gentoo systems as production machines for a number of our clients. I would really like it if it were possible to bring this current as of at least Rsync version 2.6.6 (the version that is stable in Cygwin now), but 2.6.7 would be even better. I am talking support for "write only" repositories, updated -permissions handling- options (so that a read-only file can be uploaded read-write), auto-creation of a P filter for the backup files, -E flag, chmod settings in .conf, pre/post-xfer-exec, and a whole slew of other niceties that I keep upgrading to "TESTING" version of rsync to get. It doesn't help my case out much to have to explain to another person that "for XYZ option, you must upgrade rsync to the 'testing' branch". Seriously, what's really holding this back?
I have wierd problems with 2.6.3, and 2.6.4 and 2.6.6. Lots of them, downgrading to 2.6.0 has fixed more problems than caused. I too have some discomfort here, and I am wondering what we all should to about it?
(In reply to comment #6) > I have wierd problems with 2.6.3, and 2.6.4 and 2.6.6. Lots of them, > downgrading to 2.6.0 has fixed more problems than caused. I too have some > discomfort here, and I am wondering what we all should to about it? Uh, how about filing bugs detailing said "wierd problems" instead of just non-specific "it's broken for me" comments which don't add anything to the conversation? Personally, I've been running rsync-2.6.6 on the 6 machines that I admin since I initially opened this bug and I haven't seen a single problem. I also note that at this immediate moment, there aren't any bugs in bugzilla that seem to explictly block an upgrade to 2.6.6 (or beyond). So, I ask the maintainers, again after 2 _more_ months, what's the hold up and how can I help further the process?
One thing I've noticed that seems wrong with rsync 2.6.7 is that --dry-run doesn't work unless -v is specified. But otherwise I have not had any problems.
rsync 2.6.8 has the same --dry-run problem (no output unless -v is specified). Should I make a separate bug for this?
prob best to file the bug here: https://bugzilla.samba.org/enter_bug.cgi?product=rsync
(In reply to comment #0) > Ok, so I see that we're still stuck at rsync-2.6.0 (released Jan 2004 (two > years ago as of this writing)) because of mysterious problems with other > versions (bug: 49933 and the related (but unanswered) bug: 90394), but what > about now? > > It's been almost a year since anyone visibly poked at rsync, but there are > newer, but "unstable", versions available in portage. Is there any plan for > migrating any of those newer versions (especially >=2.6.5) into stable or are > we just going to stick with 2.6.0 for all time? > > I'm willing to put my installation where my mouth is if I can help move this > process along in any way. > (In reply to comment #10) > prob best to file the bug here: > > https://bugzilla.samba.org/enter_bug.cgi?product=rsync > Check the changelog for rsync v2.6.7 before you do this. The change to remove --verbose from --dry-run is listed in there. My point is that the behavior you see is intentional. Probably so that you can specify --verbose if you really want the info, or --stats if you just want the stats information.
Apologies. I should have double checked the Changelog. However I would argue that this is a mis-feature. This seems to me to be "surprising" behaviour for the tool (and hence bad user interface design). But this probably isn't the forum for that discussion :-)
(In reply to comment #12) > Apologies. I should have double checked the Changelog. > However I would argue that this is a mis-feature. This > seems to me to be "surprising" behaviour for the tool > (and hence bad user interface design). But this probably > isn't the forum for that discussion :-) > I welcome the change, from a "new user" standpoint the expected behavior from a --dry-run option (IMO) would be to act exactly like a regular rsync, without altering anything. Anyhow, that aside, this should have warranted a bump to v 2.7.0 due to the "fallout" from such a feature change.
BTW, this seems to have been resolved. rsync-2.6.8 is now in the "stable" tree (and already has another bug against it).
done
