Mafia SVN for Scripts?

fronobulax said:
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?
Click to expand...

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

Winterbay said:
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 :)
Click to expand...

4 files? Don't follow.
 
roippi said:
4 files? Don't follow.
Click to expand...

  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.
 
Bale said:
myfile - will have
Click to expand...

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.
 
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.
 
Theraze said:
and whether that version lives in svn/ or data/ the same conflicts would happen if the files are changed.
Click to expand...

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.
 
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?
Click to expand...

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.
 
Maybe if scripts want to store data persistently, they should write that data into a *different* file - one that is *not* distributed though svn?
 
xKiv said:
Maybe if scripts want to store data persistently, they should write that data into a *different* file - one that is *not* distributed though svn?
Click to expand...

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.
 
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.
 
roippi said:
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.
Click to expand...

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?
 
Bale said:
A more contentious issue would be /images/relayimages. What about /svn files in that directory?
Click to expand...

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.
 
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.
 
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.
 
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.
 
You must log in or register to reply here.
Back
Top