Please, more care about being compatible to yourself

Zugschlus commented 8 years ago

Hi,

I recently learned the hard way that a borgbackup 0.29 client won't talk to a borgbackup 0.28 server. This is a severe annoyance when you backup like more than five clients since one cannot to a backup any more when test clients are more ahead of the server regarding borg backup version.

Please consider not breaking backwards compatibility this way. It destroys trust in the program by prompting kneejerk questions like:

will I be able to restore from my 0.24 repository with a 0.29 client and a 0.29 server?
will there be some time when a 0.29 server won't write to a 0.28 repository?
will there be some time when the remedy for some issue will be "just delete your repository and start over"?

Being bitten by issues like that with rdiff-backup, another backup program written in python, I'd like to make sure that this won't happen with borgbackup..

Greetings Marc

rumpelsepp commented 8 years ago

Please read the documentation:

EXPECT THAT WE WILL BREAK COMPATIBILITY REPEATEDLY WHEN MAJOR RELEASE NUMBER CHANGES (like when going from 0.x.y to 1.0.0).

Once borg reaches 1.0 I guess they will care a lot about backwards compatibility.

ThomasWaldmann commented 8 years ago

You don't need to learn that "the hard way", it's written quite clearly at the very top of the 0.29 changelog entry.

Also, the issue only relates to the rpc api, not to the repository / storage format.

So, anything left here or can I close this?

There's already a ticket about compatibility policy discussion, btw., so that part is duplicate.

Zugschlus commented 8 years ago

rumpelsepp, 0.28 to 0.29 is not a major version change.

Zugschlus commented 8 years ago

ThomasWaldmann, so there are no guarantees about repository/storage formats?

How do you suggest packagers package your software? Which packaging software supports having more than one version of a package installed?

ThomasWaldmann commented 8 years ago

I just said your issue does not relate to the repository/storage format.

Zugschlus commented 8 years ago

How do you suggest packagers package your software?

Zugschlus commented 8 years ago

This is now Debian bug #809136. Probably a show-stopper for borgbackup in Debian.

ThomasWaldmann commented 8 years ago

@Zugschlus what's the problem of just updating the borgbackup package to 0.29 in debian? you don't want 0.28 AND 0.29 parallel, you just want 0.29.

Zugschlus commented 8 years ago

Debian is more than just the development version, you know? We have a reputation of making a stable release once in a while, and at least I would want to backup a system running Debian unstable to a server running Debian stable, which is very likely to have an older version of borgbackup installed.

niieani commented 8 years ago

May I suggest a way to mitigate this problem? Instead of using packages, one could build docker images for each release of borgbackup (use tags to signify version numbers). This way we could always run the appropriate version for the appropriate client, without the headaches involved with backwards compatibility.

ThomasWaldmann commented 8 years ago

@niieani the complaint comes from a debian package maintainer and refers to the debian package, so your solution does not help there.

Zugschlus commented 8 years ago

@nileani, first I thought you made a really good joke. Then I realized that you were being serious. This made me stop laughing in a millisecond. Am really sad now.

RonnyPfannschmidt commented 8 years ago

Docker is pretty much the poorest solution to the actual problem

anarcat commented 8 years ago

while i agree this is a problem for debian, it is true that we are not committed yet to API stability. so i think it is fair to block borg from entering debian testing for now if that's such a concern for the debian packagers.

i don't think however, that it should be the case: it can be clearly stated in the package's README.Debian that the API stability has yet to be refined and that such problems could occur until 1.0 is released.

finally, just a reminder that this is not a storage format issue: just an API modification. borg can still read older backup formats, it can even convert repositories from the prehistoric attic format...

anarcat commented 8 years ago

i have added a comment to the debian bug report, which wasn't linked properly here: https://bugs.debian.org/809136

i don't believe this is a showstopper for packaging borg in debian, and i think this issue can be closed: i think the understanding is that borg 1.x will be more API stable, and even without that, Debian has fine ways of dealing with such issues already (backports, namely).

skorokithakis commented 8 years ago

Why not make the new versions compatible with older versions for a reasonable time (e.g. a year)? That would make 0.29 choose the old API when talking to a 0.28 server, and things would work. Then you could break backwards-compatibility in version 0.32 (or whatever), when you'd already have four versions that supported the new protocol.

Breaking compatibility in a single version isn't fantastic, especially when the solution is to just keep the old code around a bit longer and issue deprecation warnings.

neutrinus commented 8 years ago

Folks, maybe borg is just not ready to be packaged in debian? It's nothing to be ashamed of. Or just put in experimental, as borg is in it's experimental phase.

ThomasWaldmann commented 8 years ago

Yeah, remove it and use attic, which has about a hundred bugs more, but is sta(b)le.

skorokithakis commented 8 years ago

@ThomasWaldmann, that's not very constructive. It's fine to say "we're still experimental, don't use us because things will break", and it's fine to decide that supporting legacy code for a few releases is too much of a hassle, but it's not fine to say "it was in the changelog, so sucks to be you". Right now it's not clearly communicated that upgrades may stop things from working.

I use a backup host that supports borg and I don't have access to their machine to upgrade it. Does that mean I'm stuck on 0.28 client-side until they decide to roll out 0.29+ across their entire infrastructure? Getting defensive and closing the ticket isn't going to solve any of this.

anarcat commented 8 years ago

On 2016-01-19 10:15:50, Stavros Korokithakis wrote:

@ThomasWaldmann, that's not very constructive. It's fine to say "we're still experimental, don't use us because things will break", and it's fine to decide that supporting legacy code for a few releases is too much of a hassle, but it's not fine to say "it was in the changelog, so sucks to be you". Right now it's not clearly communicated that upgrades may stop things from working.

How would you expect those things to be documented better? My understanding of the current documentation is that we make this pretty clear now.

I use a backup host that supports borg and I don't have access to their machine to upgrade it. Does that mean I'm stuck on 0.28 client-side until they decide to roll out 0.29+ across their entire infrastructure?

I believe so, yes. Is this rsync.net? Maybe we can arrange something with them... and even without: you can usually deploy your own stuff directly there, no need to depend on their implementation.

Getting defensive and closing the ticket isn't going to solve any of this.

Well, it does solve the problem from borg's point of view: unless there are more constructive suggestions on how to fix this other than "don't do what you just did", there isn't much we can do.

Borg is not 1.0 yet. We are working towards it, but it's not there yet. It won't keep it from Debian (see the discussion in the aforementionned bug report) and it shouldn't keep you from running it on your infrastructure. But of course, the API may change until 1.0. And then, it can change again until 2.0.

That is the nature of software, it's hard to keep those things future-proof when there's very little people actually working on the project. All the talking won't change much for this (especially since this was previously discussed in other issues in this bugtracker).

If you can state clearly what your situation is, i am sure we can sort it out.

a.

Jesus died for his own sins, not mine.

CRASS, 1978

skorokithakis commented 8 years ago

How would you expect those things to be documented better? My understanding of the current documentation is that we make this pretty clear now.

I would expect the binary itself, when run, to say "Warning: Your server is running 0.28. That version is deprecated and will stop working after 0.30, please upgrade". For a good deprecation example, see Django, they generally do a good job.

Is this rsync.net?

Yes, but I was using them as an example of "what will I do if this happens again next version?". rsync.net have deployed 0.29 (it was deployed fairly recently, so they started off at 0.29). You can't deploy your own stuff there AFAIK.

Well, it does solve the problem from borg's point of view: unless there are more constructive suggestions on how to fix this other than "don't do what you just did", there isn't much we can do.

But there are more constructive suggestions: Issue deprecation warnings on the commandline and keep support for N versions.

Borg is not 1.0 yet. We are working towards it, but it's not there yet.

This is less about borg being unstable and more about deprecations being very abrupt. Clearly there are some users here who were affected by this, and if users didn't know that this would happen, that, by definition, means that the documentation wasn't prominent enough.

it's hard to keep those things future-proof

This isn't about future-proofing, though. It's about past-proofing. It can't be that hard to keep old code around depending on the server version, surely.

anarcat commented 8 years ago

On 2016-01-23 09:45:42, Stavros Korokithakis wrote:

How would you expect those things to be documented better? My understanding of the current documentation is that we make this pretty clear now.

I would expect the binary itself, when run, to say "Warning: Your server is running 0.28. That version is deprecated and will stop working after 0.30, please upgrade". For a good deprecation example, see Django, they generally do a good job.

Unfortunately, it's basically impossible to tell, from version X, if version X+1 will be incompatible at this point, without giving false warnings all the time.

For example, when 0.28 was released, we did not know 0.29 would break compatibility. We could have made an intermediate release (say 0.28.2) that would have made such a warning, but it would have just postponed the inevitable.

By the way, your belief that Django does a good job at deprecation is not shared by everyone, look at this blog post for a more critical example:

http://thomas.goirand.fr/blog/?p=260

Honestly, if I had it my way, Borg would be API-stable when 1.0 would be released, and there would never be a 2.0 release (ie. we would never break API again). But we just can't afford that kind of garantee, nor can any project, in my opinion. It would assume that we were right, have always been and will always be. We don't have that kind of pretense.

I certainly will do my best to maintain borg in the longer term. I am deeply interested in having my backups basically working forever, so it's quite likely that the current storage will stick around or be convertible forever. Of course, that assumes dependency on me, but people need to step up or this won't happen. It also assumes I can agree with @tw, something which is not always possible. ;)

Unfortunately, I don't do remote backups right now, so that area is less of a concern for me. But the specific problem that was raised here (that client/server need to have similar versions) is a problem that I have had to deal with in the past with rdiff-backup, and found proper solutions for (backports and configuration management) that were not a big problem in the long run. A commitment for API-stability in 1.x basically answers that requirement for me, something that rdiff had trouble with anyways.

Is this rsync.net?

Yes, but I was using them as an example of "what will I do if this happens again next version?". rsync.net have deployed 0.29 (it was deployed fairly recently, so they started off at 0.29).

So basically, rsync.net are compatible with the latest version of borg, and you just need to upgrade your clients, which you control. You said earlier:

Does that mean I'm stuck on 0.28 client-side until they decide to roll out 0.29+ across their entire infrastructure?

The answer is: no, the server side is running 0.29, and you never had this problem because if you were running 0.28, it would never have worked in the first place. If you meant that backups are not working with rsync.net because they run 0.29 and you run 0.28, and "does that mean you need to upgrade all your clients to 0.29", the answer is "yes, you can".

You can't deploy your own stuff there AFAIK.

I thought you could, but it does seem like there's a restricted set of commands you can run. The fact that they are running the latest borg version makes the argument kind of moot, however.

Well, it does solve the problem from borg's point of view: unless there are more constructive suggestions on how to fix this other than "don't do what you just did", there isn't much we can do.

But there are more constructive suggestions: Issue deprecation warnings on the commandline and keep support for N versions.

We have deprecation warnings for commandline arguments. It's unclear to me how you want those to happen with the server communication, because it's impossible to do such warnings unless we warn every time you connect to a server.

We will support the 1.x API for a long time, I hope. We support N versions right now, where N is 1, because we are not at the 1.x stage yet. Just saying "N" is not good enough: we need to make that number explicit, because we don't have the manpower to support all releases of borg ever produced.

There is a place where discussions about such support timeframes is happening, and it is #26. There we raised questions of semantic versionning, support timeframes, and other issues, which were clearly and honestly discussed. I suggest you read up on those before just asking for a pie in the sky. :)

Borg is not 1.0 yet. We are working towards it, but it's not there yet.

This is less about borg being unstable and more about deprecations being very abrupt. Clearly there are some users here who were affected by this, and if users didn't know that this would happen, that, by definition, means that the documentation wasn't prominent enough.

I agree. However, I don't know how to fix that myself. For me, the problem space was clearly stated and the documentation was obvious, but I am more deeply involved in the project, and specifically in that area, so I am biased.

I would welcome comments on how to fix that. Just blanket warnings don't seem appropriate right now. :)

it's hard to keep those things future-proof

This isn't about future-proofing, though. It's about past-proofing. It can't be that hard to keep old code around depending on the server version, surely.

Future proofing is past-proofing when you're in the future.

Which we are in now, from the perspective of 0.28 users. :)

And yes, it is that hard, unless you have someone to do it. Which it seems that we don't, unless you volunteer. ;)

Sorry for the long response, i hope that clears things up for everyone.

a.

skorokithakis commented 8 years ago

For example, when 0.28 was released, we did not know 0.29 would break compatibility.

Yes, but 0.29 knows that it's breaking compatibility with 0.28, so it can say "okay, I'm talking to a 0.28 server, so I'll just print some nasty messages about upgrading to the console and use the old code to talk to the old server". That would make backups work, although possibly with some loss of new functionality.

But we just can't afford that kind of garantee, nor can any project, in my opinion.

That's fine, as long as the binary (on-disk) format is documented. This isn't "my backups are gone" bad, it's just "I can't access my backups without some hassle" bad.

If you meant that backups are not working with rsync.net

I meant "my backups will stop working the minute you release 0.XX because rsync.net will still be on 0.29 and there won't be a time window where nothing breaks". If you release a client that breaks compatibility with the version immediately before it, then rsync.net will have some users' clients breaking unless they upgrade right that second. You can see why this would be a problem for them and for me (the customer and borg user).

It's unclear to me how you want those to happen with the server communication, because it's impossible to do such warnings unless we warn every time you connect to a server.

Yep, that's exactly how. Every time I connect a 0.29 client to a 0.28 client I would expect to see "upgrade your server because it's going to stop working when 0.32 rolls out".

Just saying "N" is not good enough: we need to make that number explicit, because we don't have the manpower to support all releases of borg ever produced.

I don't mean you should support N API versions, just N package versions forward. For example, if you change an API call to return {"foo": ["bar"]} rather than {"foo": "bar"}, I would expect you to leave the code handling the old structure in the new version and select the code path based on the version of the server you're talking to. I don't expect you to have that for the next three API changes, just the next three releases, the rest of which probably won't see any other API change.

Just blanket warnings don't seem appropriate right now.

I don't see why not. It seems to me that supporting the old server and issuing a warning fixes the problem cleanly for everyone.

Future proofing is past-proofing when you're in the future.

"Future-proofing" = "Forwards compatible" = "The 0.28 release should have code to deal with it."

"Past-proofing" = "Backwards compatible" = "The 0.29 release should have code to deal with it."

Currently, none of the two happens. The 0.29 release just can't talk to 0.28 and vice-versa.

And yes, it is that hard, unless you have someone to do it.

Can you go into some more detail about what's hard about basically having this:

if server_version.minor < 29:
    logging.warning("Upgrade your server, it'll stop working on version 0.32.")
    old_code()
else:
    new_code()

You have old_code() already, you just added new_code(), my proposal pretty much boils down to "don't remove old_code() yet".

anarcat commented 8 years ago

On 2016-01-23 20:12:20, Stavros Korokithakis wrote:

For example, when 0.28 was released, we did not know 0.29 would break compatibility.

Yes, but 0.29 knows that it's breaking compatibility with 0.28, so it can say "okay, I'm talking to a 0.28 server, so I'll just print some nasty messages about upgrading to the console and use the old code to talk to the old server". That would make backups work, although possibly with some loss of new functionality.

We can't deprecate code and then not remove it, it makes no sense. :) If we deprecate code, it goes away to never return. It's the whole point.

I agree that printing a meaningful error message is good however.

[...]

If you meant that backups are not working with rsync.net

I meant "my backups will stop working the minute you release 0.XX because rsync.net will still be on 0.29 and there won't be a time window where nothing breaks". If you release a client that breaks compatibility with the version immediately before it, then rsync.net will have some users' clients breaking unless they upgrade right that second. You can see why this would be a problem for them and for me (the customer and borg user).

I suggest you take that complaint with rsync.net rather than borg developers. :) Furthermore, this will be a problem only if you upgrade all your clients to 0.XX. If you wait for rsync.net to upgrade, you will be fine.

It's unclear to me how you want those to happen with the server communication, because it's impossible to do such warnings unless we warn every time you connect to a server.

Yep, that's exactly how. Every time I connect a 0.29 client to a 0.28 client I would expect to see "upgrade your server because it's going to stop working when 0.32 rolls out".

And when 0.32 rolls out? It will just crash. That is what was done here, it is just the deprecation step was skipped in this case.

Just saying "N" is not good enough: we need to make that number explicit, because we don't have the manpower to support all releases of borg ever produced.

I don't mean you should support N API versions, just N package versions forward. For example, if you change an API call to return {"foo": ["bar"]} rather than {"foo": "bar"}, I would expect you to leave the code handling the old structure in the new version and select the code path based on the version of the server you're talking to. I don't expect you to have that for the next three API changes, just the next three releases, the rest of which probably won't see any other API change.

Now you say "3" instead of "N", that's progress. :) Also, the "next three releases" could be released in a unexpected timeframe, i am not sure what that buys you (e.g. two minor fixes could be published the same day as a major release for various reasons, and then you "burned" your 3 releases and should logically remove the deprecation warnings).

Just blanket warnings don't seem appropriate right now.

I don't see why not. It seems to me that supporting the old server and issuing a warning fixes the problem cleanly for everyone.

I think that is because we don't understand each other about what a "blanket warning" means.

Future proofing is past-proofing when you're in the future.

"Future-proofing" = "Forwards compatible" = "The 0.28 release should have code to deal with it."

"Past-proofing" = "Backwards compatible" = "The 0.29 release should have code to deal with it."

Currently, none of the two happens. The 0.29 release just can't talk to 0.28 and vice-versa.

And yes, it is that hard, unless you have someone to do it.

Can you go into some more detail about what's hard about basically having this:
if server_version.minor < 29:
    logging.warning("Upgrade your server, it'll stop working on version 0.32.")
    old_code()
else:
    new_code()
You have old_code() already, you just added new_code(), my proposal pretty much boils down to "don't remove old_code() yet".

I won't. This was @TW's decision, and I am a bit weary of trying to justify it in the face of lack of support all over the place (including from @TW). My point was just that I was hoping that 1.0 would fix some of that behaviour, and that the road towards that was risky and it was acceptable that some of those changes be applied.

It's not even clear to me what happens when 0.28 talks to 0.29: what I understand is that commandline flags changed and server and clients became incompatible. I have yet to see how that fails in practice, and I haven't seen an actual bug report of what happens in this case, so the code example you have given above is actually really hard to do because I have no idea of what you want to be fix or where to start debugging the problem.

Give me a test case and i'd be happy to look into it. And if it's that easy, you're welcome to provide pull requests since you seem to be familiar with Python.

a.

Le Québec ne rêve plus de devenir une société modèle: voilà son problème d'environnement.

Pierre Dansereau (1911 - 2011)

skorokithakis commented 8 years ago

We can't deprecate code and then not remove it, it makes no sense.

You can remove it after a grace period, which is what the problem was here. There was no grace period, you just removed it right away.

I suggest you take that complaint with rsync.net rather than borg developers.

I don't know, if you consider deprecating code without any grace period between releases to be a user problem, I'm not sure there's much to discuss. What you're saying here is "never run the latest borg stable, wait a few months/years/however long it takes for your server to catch up".

it is just the deprecation step was skipped in this case.

Which is the entire point of the discussion. The issue here is that the deprecation step was skipped. Not skipping the deprecation step would fix this.

Also, the "next three releases" could be released in a unexpected timeframe, i am not sure what that buys you

Feel free to substitute "next three releases" with "next three releases or three months, whichever comes later", or any other reasonable timeframe you feel comfortable supporting. Django, for example, leaves things in for one minor release before removing them.

and should logically remove the deprecation warnings

The timeframe is a minimum, not a maximum. It's so users know that it won't break before X time passes, not that it will break after X time passes.

It's not even clear to me what happens when 0.28 talks to 0.29

I just tried it:

03:48:53 $ borg init ssh://localhost//tmp/borgrepo
Local Exception.
Traceback (most recent call last):
  File "/tmp/borg29/lib/python3.4/site-packages/borg/archiver.py", line 1261, in main
    exit_code = archiver.run(args)
  File "/tmp/borg29/lib/python3.4/site-packages/borg/archiver.py", line 1215, in run
    return args.func(args)
  File "/tmp/borg29/lib/python3.4/site-packages/borg/archiver.py", line 92, in do_init
    repository = self.open_repository(args, create=True, exclusive=True)
  File "/tmp/borg29/lib/python3.4/site-packages/borg/archiver.py", line 64, in open_repository
    repository = RemoteRepository(location, create=create, lock_wait=self.lock_wait, lock=lock, args=args)
  File "/tmp/borg29/lib/python3.4/site-packages/borg/remote.py", line 161, in __init__
    raise Exception('Server insisted on using unsupported protocol version %d' % version)
Exception: Server insisted on using unsupported protocol version 1

Platform: Linux zeus 3.19.0-47-generic #53-Ubuntu SMP Mon Jan 18 14:02:48 UTC 2016 x86_64 x86_64
Linux: Ubuntu 15.04 vivid  LibC: glibc 2.9
Python: CPython 3.4.3

I'm not exactly sure what changed that deprecated protocol 1, but it looks like there could be a check for the server protocol version so the client could speak that. It would be much better for users if you said "okay, we'll make protocol v2, but we'll speak both for a while to give people time to migrate", instead of "okay, we're making v2, everyone who's on v1, too bad".

A very naive suggestion is to have one class or file for each protocol, and do something like:

if version == 1:
    from protocolv1 import RemoteRepository
elif version == 2:
    from protocolv2 import RemoteRepository
else:
    print("I don't speak that version")
    sys.exit(1)

anarcat commented 8 years ago

On 2016-01-23 20:55:57, Stavros Korokithakis wrote:

$ borg init ssh://localhost//tmp/borgrepo

wait what? how can that connect to a different version?

Exception: Server insisted on using unsupported protocol version 1

Okay, now we're talking. :)

I'm not exactly sure what changed that deprecated protocol 1, but it looks like there could be a check for the server protocol version so the client could speak that. It would be much better for users if you said "okay, we'll make protocol v2, but we'll speak both for a while to give people time to migrate", instead of "okay, we're making v2, everyone who's on v1, too bad".

So here's what happened here:

https://github.com/borgbackup/borg/blame/master/borg/remote.py#L19

https://github.com/borgbackup/borg/commit/6d083c06954ca3a4c289d978a1d36eaf84b52c45

The commitlog is:

increase rpc protocol version to 2

this is needed because due to the locking improvements, some rpc calls' signature changed slightly.

So the problem here that the RPC API changed. What you are suggesting is that we duplicate a whole tree of functions (and they go deep) because arguments were added to those RPC functions. in particular, the open call was changed:

def open(self, path, create=False, lock_wait=None):
def open(self, path, create=False, lock_wait=None, lock=True):

now, you could "fork" that function and call it "open28" and "open29", but that would be rather ugly, and would keep the broken code around, something which we don't want. it could also create unpredictable results: should locking be on or off? that seems rather important!

interestingly, there is a default argument there, so it's actually possible that the thing would work if you remove the API control check, which is designed to do more or less what you are asking for... although it is not letting you go through with the command, because the locking semantics changed, you could still run backups from 0.28 to 0.29 with the following patch:

https://github.com/anarcat/borg/commit/9101a53a20dd7eeb1cb6509a2fc6f1c7f6d4da7c

of course, this would need to be applied on the 0.28 client. the 0.29 server doesn't care at all: there is no check on that side. i tested a similar patch against 0.28 (the above won't apply because RPC_PROTOCOL_VERSION wasn't a constant then), and it works:

[1002]anarcat@angela:~$ ~/.virtualenvs/borg0.28/bin/borg init --remote-path ~/.virtualenvs/borg/bin/borg ssh://localhost/tmp/borg-0.28
Initializing repository at "ssh://localhost/tmp/borg-0.28"
anarcat@localhost's password:
Server insisted on using unsupported protocol version 2
Encryption NOT enabled.
Use the "--encryption=repokey|keyfile" to enable encryption.
Synchronizing chunks cache...
Archives: 0, w/ cached Idx: 0, w/ outdated Idx: 0, w/o cached Idx: 0.
Done.
[1003]anarcat@angela:~$ ~/.virtualenvs/borg0.28/bin/borg create --remote-path ~/.virtualenvs/borg/bin/borg ssh://localhost/tmp/borg-0.28::test /etc/motd
anarcat@localhost's password:
Server insisted on using unsupported protocol version 2
reading files cache
processing files

the problem with this patch is that there's a reason why this change was introduced, as mentionned above. i am not sure of the justification, as I didn't introduce it myself. i am guessing that ignoring those warnings may yield inconsistencies in the way locks are managed, among other things.

again, i didn't make that change, so i don't exactly know the reason, but as you can see, there are easy workarounds. but the point is: semantics changed, and the RPC protocol was changed. that's good: it keeps your backups working, if you upgrade. if you don't, they stop working, but then they're not corrupted or broken, which is worsed than "pause" backups, which you obviously can fix more much easily than broken backups.

if you wish to carry this conversation further, i would suggest you start with a pull request based on the above patch (maybe with a prompt to ask for confirmation from the user before going ahead) and the broader compatibility timeframes discussions in #26.

thanks.

Government is the Entertainment division of the military-industrial complex.

Frank Zappa

skorokithakis commented 8 years ago

wait what? how can that connect to a different version?

The first borg is in a virtualenv, the second is the system one.

would keep the broken code around, something which we don't want.

The question is, is not keeping broken code more important than having every user's installation break? People won't like you if you say yes, which is what is happening here.

it could also create unpredictable results: should locking be on or off? that seems rather important!

Yep, that's why the code would print big big warnings explaining this every time the old function was used.

this would need to be applied on the 0.28 client. the 0.29 server doesn't care at all

I think you got that backwards, 0.28 server, 0.29 client. It would have to be applied to the 0.29 client, yes.

Wait, have we been talking about opposite things all this time? :)

anarcat commented 8 years ago

oh i see - then it is a problem:

[1142]anarcat@angela:~$ ~/.virtualenvs/borg/bin/borg init --remote-path /home/anarcat/.virtualenvs/borg0.28/bin/borg ssh://localhost/tmp/borg-0.29-testfdjaskl
anarcat@localhost's password:
WARNING: Server insisted on using unsupported protocol version 1
Remote Traceback by Borg 0.28.0
Traceback (most recent call last):
  File "/home/anarcat/src/borg-0.28/borg/remote.py", line 91, in serve
    res = f(*args)
TypeError: open() takes from 2 to 3 positional arguments but 5 were given

I'd love to help you, but unfortunately, i can't, since #26 seems to be going down the drain. again, i suggest you take the discussion there.

borgbackup / borg

Please, more care about being compatible to yourself #512

a.