Mafia SVN for Scripts?

[roippi]

r12220

 

[Magus_Prime]

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

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?

 

[Winterbay]

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.

 

[Magus_Prime]

That's my core question. The file is sitting in the \data directory so why wasn't it found?

 

[fronobulax]

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

 

[roippi]

That's my core question. The file is sitting in the \data directory so why wasn't it found?

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".

 

[Theraze]

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.

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

 

[roippi]

Same issue.

Are you reporting an issue with r12222, or did you just not see my post?

 

[Theraze]

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. Sorry.

 

[Veracity]

> 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.

What's with all the "using data override" lines?

 

[roippi]

At the check dependencies step, we use FileUtilities.getReader( File f ), which eventually does

	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.

 

[Veracity]

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.

 

[Winterbay]

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:

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?

 

[livercat]

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.

 

[Winterbay]

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).

 

[bleary]

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.

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.

 

[Bale]

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.

 

[roippi]

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.

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

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:

Or the line at the end:

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.

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.

 

[bleary]

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.

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?

 

[bleary]

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.

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.