Handle file revision conflicts correctly.

[gsass1]

Right now, when revisions have conflicting files, and the user chooses to keep either on of them, upon validation one revision will be tracked as corrupted.

This is extremely stupid and should be solved. What I think of is

• maintain a separate database for file conflicts
• each entry contains the name of the file and what revision was chosen for the conflict solution
• have the file handling modules use this database accordingly

[dd86k]

iirc git uses the file timestamps (likely Last Modified) for changes.

Or else it's just a decent idea from my mind. Instead of checking a database, we'd be checking. Maybe even via https://msdn.microsoft.com/en-us/library/d5da1572.aspx.

[gsass1]

I don't see really how we could do it without some sort of database.

Suppose we have two revisions, they both reference the file "materials/thing/shiny_texture.vtf".

Say we install R1 first, no problem. Then we try to install R2 but there's a conflict. Now there should be two options for the user: keep the file as it is or replace the file with the version from R2.

Currently, this creates a bug in both cases. If we replace the file then R1 is now missing a file (checksum comparison fails). Otherwise if we intend to keep it the same false-validation applies to R2. What we need is a way of knowing if the file was intentionally replaced by another version.

I imagine that we would hold some database of conflict resolutions, containing entries similar to this format. This entry is what would be added, if it was chosen to replace the file with R2's.

<ConflictResolution>
        <File>materials/thing/shiny_texture.vtf</File>
        <Contestants>
                <Revision>R1</Revision>
        </Contestants>
        <Winner>
                <Revision>R2</Revision>
        </Winner>
</ConflictResolution>

In general this format allows to specify an indeterminate amount of revisions which were part of the conflict (contestants), and one revision that basically "won" the resolution.

When we now try to install some revision R3 that also references this file, the same dialogue would pop up, and then depending on choice, R3 would be added to Contestants (in case we keep it as it is), or R3 would become winner and R2 would be moved to the Contestants instead.

The revision validator should also be happy now. All it needs to do is only check files that have no conflicts or whose resolution defines the being-validated revision as winner.

[dd86k]

Feels like you're trying to do a similar thing to git and its branching system at this point lol

[gsass1]

Dumbass me. Couldn't we just make a separate folder for each revision and add them as SearchPaths?

[dd86k]

Doesn't sound bad. Although you might want to really elaborate and plan that out. I have no idea on my side lol

[gsass1]

In the SFM usermod directory there is a file called "gameinfo.txt". Therein contained is an entry called "SearchPaths". Basically, these paths determine in which folders SFM is gonna search for mod files. Right now, we're creating a single directory called ponysfm in which we store all mod files. Simple solution to the conflict problem would be, to create a separate directory for each mod.

[dd86k]

Sounds neat.

[gsass1]

But ANOTHER concern is actually writing and reading from the gameinfo file. Right now we just insert a premade line after we hit the "SearchPaths" key, which is actually really stupid because depending on the file it could easily break. Solution would be to write a lexer for this file which lets use deconstruct and construct the file format again. But I'm not too sure how far down the rabbit-hole I want to go there because of this issue.

[dd86k]

A parser wouldn't be too bad but eh im lazy