[Top][All Lists]

[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'


 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]