Mafia SVN for Scripts?

Glad that sorted it. Because I was running out of ideas. Heh.

Turns out that connecting through a proxy makes the svn server challenge for credentials, whereas everyone else was allowed anonymous requests. Go figure. We needed to respond to those auth challenges or the server got unhappy with us.
 
Maybe in the last 17 pages this was mentioned, but is it the intention for us "scripters" to be able to register our scripts with some sort of central database or data file, and have the SVNs registered with mafia (in some way), so there's some sort of GUI for "major" scripts in some way?

That might be really poorly explained, but basically a place to find, BCA, snapshot, zlib, UR, WHAM, ...
 
That was answered here:

roippi said:
Long term plans-
GUI support for a script manager. Users can at a glance see what scripts they have installed and what scripts can be updated. One-click updates. Other metadata will be shown at a glance, like date of last update, author info, number of files in the project, etc.

I'd like to have installation of new scripts handled through this interface as well. It's pretty easy to have a .txt file hosted somewhere that has a list of links to repos with scripts, maybe with a quick description attached. A name filter field lets users get to the script that they want quickly. Here's where I'm not 100% sure on the direction to take with it. Who is responsible for maintaining that .txt file? How do we do quality control on it, prune obsoleted scripts, etc? Food for (eventual) thought, we have plenty of time to discuss it.
Click to expand...

The eventual implementation will probably require you to ask a minion to add or remove your script on the official list of scripts. We'd probably have a forum thread here for that subject.
 
Excellent! In the interim, I'll make some sort of temporary thread linking all of those scripts that have moved to SVN so that we'll have a clear index of larger scripts, etc.
 
For people who were making edits directly to their working copy, see r12167. It used to be awkward that you needed to manually copy any files so edited from the WC to the local copy (at least until a repo update pushed out the merged WC file), but hopefully that helps.

I've been thinking about the other half of it - people who manually edit their local copy - and I don't know if there's a solution to that problem. Thought experiment:

A user manually tweaks his charpane.ash script. We can iterate through the working copies, see there's a charpane.ash in there, and see that it differs from our local copy. Okay, overwrite the working copy with the local copy.

Then, the user decides he doesn't like his tweaks, and removes them from his local copy. We can see that the local copy again differs from the working copy, but how do we know which is the "correct" copy to overwrite the other? The user could easily just have edited the working copy.

I don't actually see a way to solve this, short of installing versioned metadata on local copy items. That's a really complicated solution for a really marginal problem.
 
As an ignorant user (who's really excited about this new functionality) I think the best way to handle that is just some end user education. Give us clear instructions on which files to edit if we want to customize an SVN enabled script. If somebody ignores these instructions, then that's their issue. :)
 
Last edited:
From the commit message:

Users who want to automatically sync after update operations can set syncAfterSvnUpdate = true.
Click to expand...

Wait! Should svn sync be run before update operations, not after? Otherwise changes will be lost during the update and there won't be anything to sync.
 
So, not that I've done anything with my SVN-version of WHAM (I think I'll put it on here when that becomes a possibility, I like sourceforge but for this type of project it has a bit too many features I don't need) but what does this error mean? (it worked fine before apart form the non-matching of my project name):
Code: 
Updating /p/winterbay-mafia/code/Winterbays Helpful Scripts
Validating      repo...
Repo validated.
C:\Privat\Dropbox\Mafia\svn\f3a93235-48a6-433b-87e5-419ffddcf400
svn:      E200029: Couldn't perform atomic initialization
 
Bale said:
Wait! Should svn sync be run before update operations, not after? Otherwise changes will be lost during the update and there won't be anything to sync.
Click to expand...

No, because that's not how svn works. (I keep saying that to various questions, and I'm not trying to be a jerk, honest)

A working copy contains metadata about the versioned files therein. One of these metadata items is the revision that each file is "pegged" to. When I make edits to a file, the contents of that file are changed, but the pegRevision remains the same.

When we do an svn update, we query the repo for the latest revision. If the repo revision is the same as the local revision, nothing happens - even though the working copy file is different from the file on the repo. When we alternately do a status query (which is entirely local), we see (from checksum metadata) that the working copy is modified from the "pristine" repo version. This is how we know when a file's status is "modified."

The magic happens when the repo revision is higher than the working copy revision - the repo file is merged into the working copy file, maintaining any local differences while adding differences from the repo. If it couldn't merge due to conflicts, it will let you know and do some other stuff that I won't get in to. It's up to you at that point to manually resolve the conflict.

-----

Anyway, long story short: syncing after update is fine. In fact it saves some redundant operations if the repo contains a higher revision - we merge, push local updates, and then sync, finding that the local file matches so we don't need to do further I/O. Doing sync beforehand adds an unnecessary push step.
 
Winterbay said:
So, not that I've done anything with my SVN-version of WHAM (I think I'll put it on here when that becomes a possibility, I like sourceforge but for this type of project it has a bit too many features I don't need) but what does this error mean? (it worked fine before apart form the non-matching of my project name):
Code: 
Updating /p/winterbay-mafia/code/Winterbays Helpful Scripts
Validating      repo...
Repo validated.
C:\Privat\Dropbox\Mafia\svn\f3a93235-48a6-433b-87e5-419ffddcf400
svn:      E200029: Couldn't perform atomic initialization
Click to expand...

I got that error just now while trying to update chit. Stranger still is that I got the exact same error while trying to update chit with tortoiseSVN, so the issue is not with anything that mafia's svn is doing. Strangest still, the issue went away on its own and I was able to update chit fine. Sourceforge hiccup maybe?
 
If I understand it correctly, svn update without sync will only push files that changed in svn - if you have checked out something with several files, and manually changed some/all of them (but didn't sync them to local copies (mafia's scripts/ folder)), you would end up having inconsistent files in scripts/ - but personally, I expect to manually call sync just after I finish the edits, and long before the next update.
 
xKiv said:
If I understand it correctly, svn update without sync will only push files that changed in svn - if you have checked out something with several files, and manually changed some/all of them (but didn't sync them to local copies (mafia's scripts/ folder)), you would end up having inconsistent files in scripts/ - but personally, I expect to manually call sync just after I finish the edits, and long before the next update.
Click to expand...

Your understanding is correct.

sync after update is only moderately useful, I agree, but it is useful to know that all of your local copies are up-to-date after an update. Especially after you commit something directly from the working copy folder - update will obviously not do anything since by definition your WC file is at the same revision as the repo, so update itself won't trigger any files to be pushed. I leave the pref on because it is a couple ms of execution time in exchange for peace of mind.
 
Awkwardly, I'm currently pretty unhappy with sourceforge since the error that Winterbay reported -

Code: 
svn:      E200029: Couldn't perform atomic initialization

happens in my testing about 1 out of 10 or 15 svn update operations. The workaround for now is.. update again after it happens. I've opened a sourceforge ticket about it. Hopefully they'll get their crap sorted quickly, since I know 100% that this wasn't happening a day ago. Pretty awful timing for whatever they did on their end to start this error. It happens equally with SVNKit or TortoiseSVN, so there's some solace in the fact that it has nothing to do with mafia's svn implementation.

Winterbay - after you check your project out with the latest revision, it should give you a nicely formatted WC folder. You can safely delete the awful-named working copy folder from svn/.
 
Maybe try out GitHub to see how it plays with the SVN stuff since ~supposedly~ it works?
 
roippi said:
happens in my testing about 1 out of 10 or 15 svn update operations.
Click to expand...

Yeah, it's pretty random:
> svn update

Updating /p/mafiachit/code
Validating repo...
Repo validated.
C:\Users\David\Dropbox\KolMafia\svn\mafiachit
svn: E200029: Couldn't perform atomic initialization

> svn update

Updating /p/mafiachit/code
Validating repo...
Repo validated.
C:\Users\David\Dropbox\KolMafia\svn\mafiachit
At revision 18
Done.
Click to expand...
 
If people want to use googlecode, that's more of an option with r12169.

Holy crap is it unintuitive to set up (it's fine once you get going, but geez) so I can provide some help for those who are confused by it but really want a sourceforge alternative.
 
Sourceforge's ticket system is blowing up with people reporting the "atomic initialization" thing so it will almost certainly be a highest-priority fix for them.

I suppose it's good that this happened early on in our svn feature release cycle so everyone is aware of the pitfalls of trusting third-party hosting for our scripts. It's free and whatnot, so can't complain too much, but intermittent service outages are not exactly what you want in a host. I've used sourceforge svn repos for this project and several others over the years and this is the first time something like this has happened (all of Sourceforge went down a few months back, so I guess that counts too). So I'm willing to give them the benefit of the doubt for now.

Also the fact that the timing of this coincides with the rollout of mafia's svn stuff is HIGHLY SUSPICIOUS CONSPIRACY THEORY FUEL.

ETA: yep, they just pushed their fix.
 
Last edited:
You must log in or register to reply here.
Back
Top