Provide ability to rollback a `cargo update`

[huonw]

It's possible to a cargo update to fail/be suboptimal, e.g. #2064 or pick up a broken version of package, so it would be nice to be able to reset to a known working state (and then be more precise about the updates). Something like cargo update --reset or cargo update --rollback.

This would presumably have to store a copy of the old Cargo.lock, in /path/to/project/.cargo or with the global database. It would also be mainly focusing on library development, since theoretically all binaries will be version-controlling their Cargo.locks (although I'm sure not all will).

Thoughts?

[alexcrichton]

I've always thought this was basically just git checkout Cargo.lock along the lines of letting VCS take care of this kind of rollback instead of having support in Cargo itself. I can see, however, where this doesn't quite cut it in all situations.

[huonw]

Checking out doesn't work for libraries, since lock files are recommended to not be version controlled for them, and most people follow this advice (e.g. one is working on a lib, runs cargo update to pull in some new version, and accidentally gets stuck in a broken state, with no easy way to get back and continue working).

[anguslees]

This could also be as simple as rotating the existing Cargo.lock to some type of versioned/dated in-place backup file. Anything that allows the user to go "oops; mv Cargo.$backup Cargo.lock; profit"

[weihanglo]

Not if we still want this feature, since with #6371 we have cargo update --dry-run since Rust 1.33. It can also be easily done with an aid from version control systems. I'd rather avoid an extra layer of complexity.

Going to solicit feedback for a while if there are some situations cannot apply aforementioned workarounds. If not, I'll close this as "not planned"

[epage]

#5221 is about supporting resolving to a specific date which would be one way of resolving the use case in this issue.

[epage]

btw #8728 is resolved and we now recommend checking in lockfiles

[epage]

I'm proposing we close this.

With #8728 resolved, the main use case for this issue is resolved. #6371 addresses more. We also have #5221 as a potential alternative for reconstructing old lockfiles.

[weihanglo]

Make sense. Closing.

If you have a reason to keep this open, please comment here.