[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backward compatibility of next beta
From: |
Arrigo Marchiori |
Subject: |
Re: Backward compatibility of next beta |
Date: |
Sun, 2 Feb 2020 22:44:42 +0100 |
Hello Frank,
On Thu, Jan 30, 2020 at 10:57:09PM +1100, Frank Crawford wrote:
> On Thu, 2020-01-30 at 11:40 +0100, Arrigo Marchiori wrote:
[...]
> > Maybe you could find a solution by using the --remote-
> > schema parameter?
[...]
> No, the use of "--remote-schema" is the issue as it passes data between
> the two programs in a specific format that has changed between python2
> and python3 because of internal variations.
I may have not explained myself correctly, or I might not have
understood anything at all. I'll try again :-)
For what I understood: the "--remote-schema" is the template for a
command that is popen()-ed.
If your server _and client_ have two executables for rdiff-backup, say:
A) ~/rdiff-backup-old/rdiff-backup
B) ~/rdiff-backup-new/rdiff-backup
What is the problem in having the client calling:
1) ~/rdiff-backup-old/rdiff-backup --remote-schema 'ssh -C %s
~/rdiff-backup-old/rdiff-backup --server'
or:
2) ~/rdiff-backup-new/rdiff-backup --remote-schema 'ssh -C %s
~/rdiff-backup-new/rdiff-backup --server'
The old version on the client would call the old version on the
server, and the new version on the client would call the new version
on the server.
What ``Old'' and ``new'' are, can be chosen with total freedom: stable
and beta? Python 2 and Python 3? Script and self-contained binary?
They would be completely independent, because the only common part
would be ssh transmitting their data.
This still requires to have the same versions of rdiff-backup on the
client and servers, but does not require an upgrade, in terms of the
new version _substituting_ the old. They could coexist side by side!
I hope I could explain myself more clearly now.
Regards,
--
rigo
http://rigo.altervista.org