Just tested this via rsync over ssh and successfully copied a directory to a remote server. The syntax was almost the same, I used -r instead of -a, like so:
$ openrsync -rv -e ssh /SRC/ example.com:/DST/
I then removed one of the remote files and re-ran openrsync. It appears to have re-uploaded all the files, not just the missing one. Like the project description says, it’s “very new and very fast-moving” so surely it will continue progressing. Nice to see pledge and unveil in there also, especially as they’re not present in the rsync package/port.
I’d probably pull off such a thing as well because there is a huge amount of users confusing OSS Maintainers with Commercial Support, which is really draining.
I understand but I think it would suck if everyone did that way. Sure we can always fork but one fork per feature sounds like a huge waste of resources.
Yeah I was confusing refusing feature requests with refusing pull requests.
A feature requests first is a good way to see if the maintainer would accept a PR (and to see if other users wants it) however. Well for the way most of us use Github, I guess we could contact the maintainer instead if his email is on his profile.
Wait, was this written “just” to avoid the standard, GPL-licensed rsync? Or what’s the story?
RPKI requires use of rsync protocol. There’s only one implementation of rsync. Internet protocols should not depend on a single implementation.
Just tested this via rsync over ssh and successfully copied a directory to a remote server. The syntax was almost the same, I used -r instead of -a, like so:
$ openrsync -rv -e ssh /SRC/ example.com:/DST/
I then removed one of the remote files and re-ran openrsync. It appears to have re-uploaded all the files, not just the missing one. Like the project description says, it’s “very new and very fast-moving” so surely it will continue progressing. Nice to see pledge and unveil in there also, especially as they’re not present in the rsync package/port.
I’m impressed! Thank you Kristaps.
You’re welcome! :)
I wonder why.
I’d probably pull off such a thing as well because there is a huge amount of users confusing OSS Maintainers with Commercial Support, which is really draining.
Exactly.
I understand but I think it would suck if everyone did that way. Sure we can always fork but one fork per feature sounds like a huge waste of resources.
I said feature requests. E.g., “can you please support –exclude”. Code is not a feature request.
It says you’ll accept their work instead of attempts to get extra work out of you for free. That seems very reasonable. :)
Yeah I was confusing refusing feature requests with refusing pull requests.
A feature requests first is a good way to see if the maintainer would accept a PR (and to see if other users wants it) however. Well for the way most of us use Github, I guess we could contact the maintainer instead if his email is on his profile.
In this case, feel free to ask here! (I’m the maintainer.)
On the other side, having feature requests open helps newcomers to see what they could help with.
If you read the rest of the README you pretty much got the answer.
Because that’s the only way your issue tracker won’t have 3000 open issues and 1000 open PRs in 5 years.
Yeah because you won’t have users because you’re kind of flipping them off.
It might be that the projects goals are purely to reach feature parity/compatibility with rsync, thus feature requests would be redundent/unnecessary.
Probably focusing on just being rsync compatible for now I guess?
I find it interesting the dev is still using CVS too.