Mafia SVN for Scripts?

When running SVN autp-update at login the following displayed in the gCLI:

Code: 
Updating bale-ocd...
G:\software\Kol\svn\bale-ocd
A https://svn.code.sf.net/p/bale/ocd/code/dependencies.txt
U https://svn.code.sf.net/p/bale/ocd/code/scripts/OCD%20Inventory%20Control.ash
https://svn.code.sf.net/p/bale/ocd/code/scripts
U https://svn.code.sf.net/p/bale/ocd/code/data/OCDefault.txt
https://svn.code.sf.net/p/bale/ocd/code/data
U https://svn.code.sf.net/p/bale/ocd/code/relay/relay_OCD_dB_Manager.ash
https://svn.code.sf.net/p/bale/ocd/code/relay
https://svn.code.sf.net/p/bale/ocd/code
At revision 6
Pushing local updates...
relay_OCD_dB_Manager.ash => G:\software\Kol\relay\relay_OCD_dB_Manager.ash
[B]NOTE: no local file named OCDefault.txt in your namespace; no updates performed for this file.[/B]
OCD Inventory Control.ash => G:\software\Kol\scripts\OCD Inventory Control.ash
Done.

OCDefault.txt does exist in the \data directory.

If it makes a difference this is on a Windows OS.

Why wouldn't the file be updated and why wasn't it found?
 
Last edited:
It wasn't updated because it wasn't found. If Mafia can't find the file, it will assume you've deleted it and thus don't want it. I think at least.
 
I reported the same issue with OCDData.txt (but with much less detail) in the OCD Thread.

The file definitely exists in my data sub-directory
 
Magus_Prime said:
That's my core question. The file is sitting in the \data directory so why wasn't it found?
Click to expand...

because bug

r12222

The simplest way to fix your project installation is to delete the project and checkout again. You could also do "svn dec ocd" a few times and then do "svn update ocd".
 
Same issue. You can see here that I have both the local version, which updated on the 10th, and the SVN version, which failed to update today.
Code: 
C:\Program Files (x86)\KoLmafia>dir ocdefault* /s/a
 Volume in drive C has no label.
 Volume Serial Number is 9AD9-D027

 Directory of C:\Program Files (x86)\KoLmafia\data

06/10/2013  10:13 PM            88,000 OCDefault.txt
               1 File(s)         88,000 bytes

 Directory of C:\Program Files (x86)\KoLmafia\svn\bale-ocd\data

06/17/2013  08:44 AM            88,323 OCDefault.txt
               1 File(s)         88,323 bytes

     Total Files Listed:
               2 File(s)        176,323 bytes
               0 Dir(s)  69,859,180,544 bytes free
 
I hadn't seen your post... I'd popped open the 30 or so unread threads and copy-pasted my results when I got to this window, but you'd committed 12222 by then. :D Sorry.
 
> svn update

Updating all SVN projects...
bale-counterchecker is at HEAD (r1)
bale-ocd is at HEAD (r7)
bale-relay-manor_unlockInfo is at HEAD (r6)
batbrain is at HEAD (r3)
slimetube is at HEAD (r2)
winterbay-mafia-autobasement is at HEAD (r20)
winterbay-mafia-wham is at HEAD (r12)
zlib is at HEAD (r5)
Using data override: data/mallprices.txt
Using data override: data/mallprices.txt
Using data override: data/mallprices.txt
Using data override: data/mallprices.txt
Using data override: data/mallprices.txt
Requests complete.
Click to expand...
What's with all the "using data override" lines?
 
At the check dependencies step, we use FileUtilities.getReader( File f ), which eventually does

Code: 
	private static final BufferedReader getReader( final BufferedReader reader )
	{
		String lastMessage = DataUtilities.getLastMessage();
		if ( lastMessage != null )
		{
			RequestLogger.printLine( lastMessage );
		}
		return reader;
	}

So I guess getLastMessage had that in it for you. I've never seen that message; it seems like it should maybe have been cleared after whatever set it before used it?

Either way it looks like using DataUtilities.getReader instead of FileUtilities.getReader will avoid that issue.
 
That print statement is the only place where DataUtilities.lastMessage is used. I would wager that variable was created just for its use. :)

I think DataUtilities.getLastMessage() should clear it.

Edit: Revision 12226 should clean up the logging of override message; it now gets printed when it actually happens, and any such message is printed only once.
 
Last edited:
Hmmmm.... I update my autoBasement script to SVN 1.8 (had ot do that in order to be able to commit from this computer) and now I get the following error in Mafia when trying to update the script:
Code: 
svn: E155021: This client is too old to work with the working copy at
'C:\Privat\Dropbox\Mafia\svn\winterbay-mafia-autobasement'      (format '31').
Done.

Is there anything we can do about that or do I need to find some way of downgrading my working copy to a lower version?
 
Until svnkit is updated to support 1.8, I think you'll have to downgrade to 1.7 (and svnkit is known for delays in supporting new svn versions). I suppose you could have 2 different versions of SVN installed and use 1.7 for mafia and 1.8 for everything else.
 
Apparently the alpha version does support 1.8. HOw difficult would it be for me to incorporate that into my Mafia if I were to build the .jar myself?

Edit: SOlved it by deleting the folder I had upgraded and re-checking out the script. I should remember to do all my checkins from the correct folder (i.e. not the one Mafia is working with).
 
Last edited:
roippi said:
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.
Click to expand...

I guess this isn't the current behavior? CHIT just updated itself via SVN and I lost all of the changes that I'd made to the version in my /relay folder.
 
It is the current behavior, but you did it wrong. You need the make your changes to the version in /svn/mafiachit/relay. Details HERE.
 
bleary said:
I guess this isn't the current behavior? CHIT just updated itself via SVN and I lost all of the changes that I'd made to the version in my /relay folder.
Click to expand...

I guess you didn't read the line before the one you quoted?

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

Or the line at the end:

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

So no, your changes in the local copy are not guaranteed to survive some/any SVN operations. The one in the working copy - i.e. the one in svn/ - will survive, as Bale linked you to.
 
Bale said:
It is the current behavior, but you did it wrong. You need the make your changes to the version in /svn/mafiachit/relay. Details HERE.
Click to expand...

Okay, but that seems like a bug or something. It should at least make a backup of my modified local script before overwriting it. I guess it would probably just make matters worse for me to make the scripts in /relay or /scripts symlinks or hard links to the files in /svn?
 
roippi said:
So no, your changes in the local copy are not guaranteed to survive some/any SVN operations. The one in the working copy - i.e. the one in svn/ - will survive, as Bale linked you to.
Click to expand...

I guess I'm confused as to why there are two copies of the same files in my kolmafia directory, one under version control and one not. Seems like it would have been much intuitive to have mafia act as if stuff under /svn/<project>/relay were under /relay and stuff under /svn/<project>/scripts were under scripts, rather than making (active) copies which are subject to getting overwritten without so much as a warning.
 
You must log in or register to reply here.
Back
Top