Mafia SVN for Scripts?

Bale said:
That also means I'll abandon zarqon's map manager because I can simply put my data files in the svn to save an extra step.
Click to expand...

That also means that your map files will no longer be freely editable by the community. Which is fine, since you are attentive. :) But less fine for the less attentive.

Unless SVN has a way to grant community access on a per-file basis. Or, alert helpers could make pull requests for updates and then the author would merely have to approve them. But that takes quite a bit more savvy than the present method of text editor + web upload form.
 
zarqon said:
Unless SVN has a way to grant community access on a per-file basis.
Click to expand...

I was looking for such a method. I can only say that sourceforge does not allow modifications of user permission on a file or directory basis, only by project.
 
Well, you *could* split project-foo into project-foo-code and project-foo-data, taht *should* work. But it will add some time. Right now, when I svn update, I am seeing about 1 second per script, and that's when I am up-to-date. (maybe there's some room for paralelization there? but don't ask me what where and how to synchronize ...)
 
xKiv said:
(maybe there's some room for paralelization there? but don't ask me what where and how to synchronize ...)
Click to expand...

The last thing I remember being done in parallel was loading character status after the choice adventure for starting Boris. That caused mafia to freeze for several people, including me, until I removed the runInParallel() command. I don't really know what the underlying cause of that problem was, or if it would be at all related to parallelizing this stuff.
 
svnkit pretty explicitly tells you that it is not thread-safe and you should only do one svn operation at a time, unfortunately. Each update operation consists of two things that hit the server: validation and update(). It's conceivable that I could optimize validation a bit more but I think it's pretty fast as-is.

The only thing I could parallelize (tell me that's a word) is the pushing of local updates, but that probably wouldn't save more than a couple ms.

I don't think that 1 sec per project is unreasonable, others may feel differently I guess.

As for permission stuff: svn itself supports per-repo, per-directory, and per-file access rights. I do not know if sourceforge gives you access to httpd to set all those things. I'd have to do some searching. In any case, you'd almost certainly have to do it through the command line, so it wouldn't be something everyone's up for.
 
roippi said:
As for permission stuff: svn itself supports per-repo, per-directory, and per-file access rights. I do not know if sourceforge gives you access to httpd to set all those things. I'd have to do some searching. In any case, you'd almost certainly have to do it through the command line, so it wouldn't be something everyone's up for.
Click to expand...

I looked thoroughly, but I couldn't find a way to set rights at that level using sourceforge. Perhaps google code allows that? If so, then it is an interesting reason to switch from sourceforge to allow other people to modify the data files.
 
xKiv said:
It's reasonable for a handful of projects.
It will be significant when we get dozens.
Click to expand...

I still think that's reasonable, but okay.

I could make a "dumb" mode that would just check if your working copy is at HEAD and skip if so. That is not at all the same as what svn update does but it would likely speed things up a bit.
 
Bale said:
Please explain the difference. If working copy is at HEAD what does it do now?
Click to expand...

Like a lot of things when you get into deeper study, you can realize that your previous understanding of a thing was only an approximation. In this case, there is something called mixed working copies. Basically, you can arbitrarily switch any subdirectory or file within your working copy to a different one - perhaps one in a different branch of the project entirely. So the majority of your WC could be from trunk/ but you switch the data/ subdirectory to be the one from your "beta" branch. You can even switch files to different revisions! I'm not explaining this terribly well, look for the documentation on svn switch to read more.

No longer is the concept of a WC being at HEAD completely valid since a WC can be a mixture of things - which is usually why a WC is described as being at BASE after an update. They are very often the same but can differ as I've poorly explained.

There's also some things it probably does with locks and properties that I'll ignore. And more advanced stuff like svn externals that I barely even grasp. Point is that stuff is complicated, but for 99% of users, a "dumb" check is sufficient.
 
Any chance we can make the SVN update be global rather than by character? That would save a bunch of server hits for those of us with multiple characters...
 
I don't know whether this is a problem with Bale's repository or with r12183 so I thought I'd ask first here. When starting mafia or issuing the svn update command I get the error:

Code: 
> svn update

svn: E170001: PROPFIND of '/p/mafia-ocd/code': 403 Forbidden (https://svn.code.sf.net)
svn: E170001: PROPFIND of '/p/mafia-ocd/code': 403 Forbidden (https://svn.code.sf.net)
SVN ERROR during update operation. Aborting...

There's a similar post in the OCD thread.

Any thoughts?
 
It looks like bale has been fiddling with permissions on that project. I don't think he's officially released that one on svn, but you'd have to ask him.

It is wrong that we stop updating entirely when that error happens rather than continuing on to the next project, I'll address that.
 
One possibility for the eventual list of scripts would be adding svn.txt to mafia's data folder. Giving commit access for that purpose seems reasonable, if needed.

That doesn't help at all with deciding how to pick which scripts are included. I don't think it will be difficult to decide when to remove a script; if people start posting that a script doesn't work, and the author doesn't show up to work on it (or says they don't plan to fix it), then it gets removed.
 
You must log in or register to reply here.
Back
Top