Using a build of the version mentioned in the title, when pulling some changes it chokes and gives the error Error: Local change error: Invalid change.

It is reproducible trying to pijul clone https://nest.pijul.com/pmeunier/vscode-pijul, which only has three changes in it to narrow things down. It happens both cloning from the Nest and cloning from a local repo. The error does not happen when using an older version.

The issue is not with cloning specifically, as I was able to clone from a small test repository I made that contained a couple of simple changes.

It likely comes as a result of the refactoring of ‘apply’.

Yes, good point. I’m not sure yet how to handle that, I don’t want to reset history. I tried to strengthen apply with this version, because I noticed that one could create “malicious” patches that could break some of the hypotheses apply relies on, which could then cause data loss.

I should try to fix that by having an option to support old patches, and only allow them before the first “new” patches in a channel.

@pmeunier

It depends on how much time you are willing to spend on it. But in the long run, having to support old things makes life harder. The ideal would be to have a way to get things migrated. How possible it would be depends on if it is reasonable to identify the “bad” patches and transform them into “acceptable” patches.

I was curious about the difference and created a new repository in which I recreated the change history of vscode-pijul. Then I output the changes to text files to compare with a diff tool (let me know if you would like me to email a tar file of the changes). It was done using a build of pijul that does not have any of my local modifications.

There are a couple of notable differences that I want to point out as the new version seems strange.

- 3. File addition: "src" in "/" 1755
-   up 1.0, new 491:496
- 
- 4. File addition: "extension.ts" in "/" 644
-   up 0.497, new 498:512
+ 3. File addition: "src\\\\extension.ts" in "/" 755
+   up 1.0, new 491:510

The important part is that it has two separators consecutively (appearing as 4 due to being the Windows separator and needing to be escaped), which causes an error when trying to reset. I recommend checking that such does not happen on Unix systems as well.

When I added the file it was done as:

PS U:\devel\temp-repo> pijul add src
PS U:\devel\temp-repo> pijul add src/extension.ts
PS U:\devel\temp-repo> pijul ls
src
src\extension.ts
PS U:\devel\temp-repo> pijul remove src/extension.ts
PS U:\devel\temp-repo> pijul ls
src
PS U:\devel\temp-repo> pijul add src/extension.ts

I did not check what files were added again before recording, but I had added an removed in several times by that point and there had not been a double separator whenever I ran pijul ls.

Trying again later with another file, the double separator does not occur until pijul record is run. And then in the recorded change, there are two path separators. In the diff before the record it was only one separator, and in the next editor that popped up it also only showed one.

If this is just a Windows problem, it will get fixed when Windows path separators it will be fixed once they are handled properly. The most concerning part is that the recorded change for adding a file in a folder is different from what is show by pijul diff before recording and is also different from what is shown in the text editor.

The other strange thing was:

- 1. File deletion: "tslint.json" 2.14
- BF:BFD 1.0 -> 2.0:13/2, F:BFD 2.13 -> 2.14:14/2
+ 1. File deletion: "" 2.14
+ BF:BFD 1.0 -> 2.0:13/2, BF:BFD 2.13 -> 2.14:14/2

It seems strange that the name of the deleted file is not being recorded now.

@pmeunier

Having thought about it more, the best approach to compatibility issues in the change store is to:

• For now, keep compatibility if possible to do with a reasonable amount of effort. Have the backwards compatibility behind a feature flag so that it can be removed later and so libpijul can be tested with its absence.
• Have clear indication (in the Readme and on the Pijul website) that there will be a one time drop of compatibility on the full stable release.
• When Pijul is getting close to ready to release, create a migration tool that will reconstruct the history of a repository. It would be somewhat similar to importing a Git repo.
• Have a clear time frame during which the migration tool would be supported so it does not become a long term effort sink.

The time spent getting the migration tool ready would serve to give more time for any lingering issues to be found before the full release.

Thanks! The migration is really benign to implement, and even to keep in the long run. The patch format hasn’t changed, it just needs a way to say “don’t check that if the version is <= 3”.

My current plan is: I’ll keep working on one or two more “scalability” features, then fix all the bugs reported here, and then call it a beta for a month or two in order to gather more feedback, and that should hopefully be close to the end ;-)

@pmeunier

The time of the full release will be the last time to drop backward compatibility until version 2. If Pijul takes off and becomes widely used, then releases of major versions that break compatibility cannot be too frequent. Especially for the change store.

Leading up to the Beta, announce a dead line for purposing changes that break backward compatibility of any part of Pijul (be it change store, network protocol, config files, or the command line interface). Then all purposed changes that break compatibility will need to be finished up and applied before Beta starts.

Do try

pijul init
mkdir x
echo "Hello World" > x/y.txt
pijul add -r x
pijul diff
pijul record -m "testing"
pijul change <hash of recorded change>

For me using a build of Pijul that has placeholder fixes for the issue with path separators on Windows, pijul diff will have ’1. File addition: “y.txt” in “x” 755. Then for pijul change` it will have ‘1. File addition: “y.txt” in “/” 755’.

It seems to be a presentation issue only though, as when I delete the file and run pijul reset the file is restored to the correct folder. But the fact that ‘pijul diff’ shows something different than pijul change after recording is disconcerting.

The issue with the invalid changes is fixed in 1.0.0-alpha.28 (just published). I didn’t need to change any format at all, the only downside is that the changes made before 1.0.0-alpha.27 will not be reversible (it would be hard to find a “downside” more minor than this).

The other issue is solved with the attached change.