πŸ‡ I think we can begin by checking github pr's. What do you have today?

🐒 Yesterday's Git integration PR tests failed. I'll begin by checking the logs.

πŸ‡ Maybe run the tests locally to see. It may appear in the machine as well. It might a simple thing.

🐒 Probably, yes. Started the tests now. I shouldn't forget to run them before testing the PR. It may save some time.

πŸ‡ Ah, yeah, maybe. Yesterday you were already at the end of workday, so it didn't matter much. But you can shorten the testing time by reducing the number of files, etc. I think a separate benchmark suite might be good to have. Tests should be shorter. Benchmarks should only run for tags.

🐒 Yup. I should shorten the tests. I should make them use a shorter list of files maybe.

πŸ‡ Local tests has passed. You'll have to check the logs.

🐒 It seems git diff --name-only --cached returns the files not yet added. That's causing an error in new repositories with stash. Stashing shouldn't run at all when there are no staged files.

πŸ‡ Git behavior between local version and remote version seems different.

🐒 I think trace should also show the git version string.

πŸ‡ You should also report a minimum git version for the commands. You're using some newer options and not all users may have them.

🐒 Yep. Let's see the version at the CI now.


🐒 Ah, I see the problem is not about versions. It's about CI doesn't configure git config --global user.email and user.name. Commits don't work without these.

πŸ‡ You should remove Git version report then. It's one more process call for no reason.

🐒 I think it should be in trace!, I can check the verbosity level and call if it's trace.


🐒 Completed xvc-config docs as well. I think I can merge it before the tests, as it's a documentation test.

πŸ‡ You seem to rush for the release.

🐒 Yeah, I want to start to test this really, on the servers.

πŸ‡ Then, go ahead, let's release a new version.


πŸ‡ It looks you're back in an evening session. I think it's time to begin to use Xvc on your torrent server.

🐒 Ah, yeah. Let's see how it goes.

πŸ‡ Create a repository for torrents. Then you can add files to it with cache-type = symlink or cache-type = hardlink.

🐒 I think creating a local storage may also help. I can use it to store files to retrieve them later.

πŸ‡ Umm. We don't have a "garbage collection" facility yet, you know. There are no file deletions at the moment. It may be better to have a repository to repository transfer feature, with SSH.

🐒 Yeah, we don't have SSH storages either. I think this highlights lack of features.

πŸ‡ It's possible to mimic Rsync storages with xvc storage new generic, but it doesn't feel quite the same.

🐒 Then, adding these three tickets.

πŸ‡ I think for 0.3.4, the command we add may be xvc file delete. You can work on this, and add rsync support as well.

🐒 There is a librsync bindings library for Rust. But it looks, it doesn't allow to transfer the file contents between hosts. There is also rusync that's similar to rsync, and implemented in Rust. There is also fast_rsync in pure Rust. It uses MD4 to calculate deltas, though. I think.

πŸ‡ None of these seem to have network capability, though.

🐒 I think it's better just to use the process for now. We are trying to come of with the fastest solution yet. We are just trying to be more general.

πŸ‡ Yes, I think we can just use the process for the time being.

🐒 Then, let's start by adding it.

πŸ‡ We should also begin to create release notes. Github can generate them from PRs. https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#configuring-automatically-generated-release-notes

🐒 Created an issue for that. Now we begin to xvc storage new rsync #111

πŸ‡ Ok. Let's do this.