Mafia SVN for Scripts?

roippi

Developer
I can't find any reason to object. Thank you.

Clarification - this will actually apply to items in scripts, relay and data, right, or are the latter two down the road?

Scripts, relay, data, images, ccs, and planting.

Resolving conflicts is pretty difficult due to the fact that there is suddenly 4 files instead of one and knowing which one to poke at can be pretty difficult :)

4 files? Don't follow.
 

Bale

Minion
4 files? Don't follow.

  1. myfile - will have some inline markup at the location of the conflict ( look for <<<<<< and >>>>> markup) showing you both what your text was and what the repo's text was.
  2. myfile.mine - Your version before the update.
  3. myfile.rOld - The pristine repo versions from before the update.
  4. myfile.rNew - The pristine repo versions from after the update.
 

roippi

Developer
myfile - will have

Ohh. I've been working on this migration thing, so "conflicts" in my brain was what happens when two svn scripts try to install the same file. Of course, conflicts. Yeah.

I may have been a bit hasty in stating how "easy" step 0 is. Image files were not a "searchable" thing before (like scripts were), and so I had to code the logic for that from scratch. Data files too - and there is an additional wrinkle that data files are cached.

I'm increasingly worried about what the right solution for data/ files is, actually. Right now, if a svn-installed script publishes updates to a file in its data/ directory, that updated file will entirely overwrite the $ROOT/data file. i.e. it will destroy any local changes to said data file. If I go ahead with this migration, local changes will happen to the svn copy of the data file - and published updates would attempt to be merged in, often creating conflicts for users that have never manually edited a single file in their svn projects. Yuck.

It seems like we might want to keep the current behavior of putting a copy of data files into the data/ directory. Those files are files that scripts routinely alter, and it feels really wonky to have scripts actually modify the svn working copy file.
 

Theraze

Active member
But there can only ever be a single working copy of it anyways, and whether that version lives in svn/ or data/ the same conflicts would happen if the files are changed. I'd say to keep things consistent and put the 'base' file in the svn/data/ and rather than have the user get lost with the conflict, only have one copy.
 

roippi

Developer
and whether that version lives in svn/ or data/ the same conflicts would happen if the files are changed.

No, there are no conflicts right now. If a script updates its svn/data/whatever data file (by svn committing a change to it), it 100% overwrites the copy in $ROOT/data/whatever. No muss, no fuss.
 

roippi

Developer
I feel like we're still not communicating.

WHAT HAPPENS NOW

Joe has a svn project, joescript. He has a data file in that project, svn/joescript/data/joescript.txt. When his script is installed via svn, the "default" version of that data file gets copied to $ROOT/data/joescript.txt. His script routinely writes to the data file in $ROOT/data.

Today, he commits an update to his repository's version of data/joescript.txt. When clients update, this new "default" data file gets copied to $ROOT/data/joescript.txt, overwriting it entirely.

WHAT WOULD HAPPEN

Joe's script routinely writes to his data file. But now, there is only one data file - svn/joescript/data/joescript.txt. Script writes to the data file are made to the svn working copy of the file.

Today, he commits an update to his repository's version of joescript/data/joescript.txt. Clients update, and all of them try to merge changes from the repo into their local working copy file. Somewhere between one and all of the merge operations fail, and now you have a ton of users complaining "why my svn broke, I didn't do anything to it."

Why are data files handled differently?

Scripts procedurally write to/ update their data files. Scripts don't procedurally write into themselves. The only time you will ever have a merge operation on a file in scripts/ (or relay, images, etc) is when the user manually modifies it, which is fine - such a user can presumably deal with conflicts.

This is a corner case (how many authors commit updates to their svn project's data files, anyway) but it is a serious issue nonetheless. Loss of local data is fine - a persistently broken script due to a failed merge that was in no way the user's fault is not fine. Merges are not something that people should ever encounter unless they manually alter their working copy files.
 

xKiv

Active member
Maybe if scripts want to store data persistently, they should write that data into a *different* file - one that is *not* distributed though svn?
 

fronobulax

Developer
Staff member
Maybe if scripts want to store data persistently, they should write that data into a *different* file - one that is *not* distributed though svn?

I feel like there is a distinction between a data file that the author of the script has determined contains data that should be the same for every user of the script and a data file that the author uses to contain data that is specific to a particular character using the script. The former is a good candidate for distribution via SVN, the latter not.

So yeah, +1.
 

roippi

Developer
I agree, yes.

But like... isn't that just what we're currently doing ? The file in $ROOT/data is physically a different file from the "pristine" file in /svn/project/data, and that's precisely why I thought we might want to keep the current behavior specifically for data files.

I dunno. The core issue here is that if I make each svn project's data/ directory resolve to the same namespace as $ROOT/data, then implicitly I am giving ASH write access to those directories (via functions like map_to_file). I don't like doing that.
 

Bale

Minion
The core issue here is that if I make each svn project's data/ directory resolve to the same namespace as $ROOT/data, then implicitly I am giving ASH write access to those directories (via functions like map_to_file). I don't like doing that.

This. I completely agree with this.

I think we can live with /data being treated differently from /relay, /script and /planting. You forgot to mention /planting.

A more contentious issue would be /images/relayimages. What about /svn files in that directory?
 

roippi

Developer
A more contentious issue would be /images/relayimages. What about /svn files in that directory?

Can scripts directly write to that directory? I didn't think so..

Assuming they can't, it's just a bit of work on my end (which I've already done) to do a search through all svn projects' image/ folders whenever we look for an image locally. Seems to work okay in my limited testing.
 

Bale

Minion
They cannot write to that directory, so that should be fine.

As for making the entire /images directory searchable in /svn... I'm a little worried that cache clear might empty images out of /svn/images unless they are in /svn/images/relayimages.
 

roippi

Developer
Nah, I wouldn't make cache clear do anything to svn image folders.

The majority of places inside mafia that touch the images folder are actually fine just being told to explicitly only to operate on $ROOT/images. Only one call site (FileUtilities.downloadImage) needs to be told to search through svn projects as well.
 

Bale

Minion
Something just occurred to me. If /svn/images would override /images and not be cleared like the rest of the cache, then an occasionally discussed concept becomes a lot more viable. Someone can make an image override for KoL by simply putting all the relevant images into his /svn/images directory and letting them take precedence. Unlike the current setup they would not get deleted by cache clear.
 
Top