Bug - Fixed SVN file confusion

guyy

Member
r12230: Deleting and re-checking-out a script can cause it to overwrite the wrong file, if there are files with the same name in different folders (deleting probably isn't necessary if you didn't have it installed yet, but for completeness...)

Code:
> svn checkout https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy

Starting Checkout...
Validating repo...
Repo validated.
Q:\Maf\svn\guyymafia-buttonfrenzy
U https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/buttonFrenzy.ash
https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay
https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy
At revision 28

Successfully checked out working copy.
Pushing local updates...
buttonFrenzy.ash => Q:\Maf\relay\buttonFrenzy.ash
Done.
Requests complete.

> svn delete guyymafia-buttonfrenzy

Uninstalling project...
relay\arcade.ash => DELETED
relay\bhh.ash => DELETED
relay\bigisland.ash => DELETED
relay\buttonFrenzy.ash => DELETED
relay\cafe.ash => DELETED
relay\galaktik.ash => DELETED
relay\gamestore.ash => DELETED
relay\hermit.ash => DELETED
relay\mallstore.ash => DELETED
relay\monkeycastle.ash => DELETED
relay\shop.ash => DELETED
[COLOR="#FF0000"]relay\spaaace.ash => DELETED[/COLOR]
relay\store.ash => DELETED
relay\town_giftshop.ash => DELETED
Project uninstalled.

> svn checkout https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy

Starting Checkout...
Validating repo...
Repo validated.
Q:\Maf\svn\guyymafia-buttonfrenzy
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/gamestore.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/galaktik.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/hermit.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/buttonFrenzy.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/shop.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/town_giftshop.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/bigisland.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/store.ash
[COLOR="#FF0000"]A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/spaaace.ash[/COLOR]
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/cafe.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/monkeycastle.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/arcade.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/bhh.ash
A https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy/relay/mallstore.ash
https://svn.code.sf.net/p/guyymafia/code/buttonfrenzy
At revision 28

Successfully checked out working copy.
Pushing local updates...
mallstore.ash => Q:\Maf\relay\mallstore.ash
bhh.ash => Q:\Maf\relay\bhh.ash
arcade.ash => Q:\Maf\relay\arcade.ash
monkeycastle.ash => Q:\Maf\relay\monkeycastle.ash
cafe.ash => Q:\Maf\relay\cafe.ash
[COLOR="#FF0000"]spaaace.ash => Q:\Maf\scripts\spaaace.ash[/COLOR]
store.ash => Q:\Maf\relay\store.ash
bigisland.ash => Q:\Maf\relay\bigisland.ash
town_giftshop.ash => Q:\Maf\relay\town_giftshop.ash
shop.ash => Q:\Maf\relay\shop.ash
buttonFrenzy.ash => Q:\Maf\relay\buttonFrenzy.ash
hermit.ash => Q:\Maf\relay\hermit.ash
galaktik.ash => Q:\Maf\relay\galaktik.ash
gamestore.ash => Q:\Maf\relay\gamestore.ash
Done.
Requests complete.

In this case, there was a relay/spaaace.ash for the script being installed/uninstalled, and an unrelated scripts/spaaace.ash from this (not installed via SVN).

When I tried to check the project out again after deleting it, a popup said that it would overwrite relay/spaaace.ash, which did not exist. Instead, it overwrote scripts/spaaace.ash, which is presumably what it was actually warning me about. There isn't a scripts folder in guyymafia/code/buttonfrenzy, so I guess it was searching for a matching file in the wrong folder. I think this was an intentional thing in a recent update, but apparently regular scripts with relay-browser-page names are an issue, since they may not be unique.
 
Last edited:

Bale

Minion
Short answer, don't do that?

Perhaps when it checks name space it should prevent scripts in /relay or a /relay subdirectory from matching a script elsewhere. Since the /relay directory has a special purpose.
 

Theraze

Active member
Same could go for any similar search. You don't really want a /script getting matched with the /relay file. And if someone is using CLI scripts and has a myusefulstuff.txt script, wouldn't want that to overwrite a /data/myusefulstuff.txt data file...
 

Winterbay

Active member
Aha! So that was what it warned me about. I guess I need to go and find my spaaaace-script again then :)
(and yes you do not need to install and delete it, it works just fine by checking it out)
 

roippi

Developer
When I tried to check the project out again after deleting it, a popup said that it would overwrite relay/spaaace.ash, which did not exist. Instead, it overwrote scripts/spaaace.ash, which is presumably what it was actually warning me about.

The issue is that the warning just displays what the default svn location is rather than the resolved rebase location in your local directory. So, yes, it was warning you about the right thing, but the message was off. We should fix that.

Also, deleting probably should have failed for that file since you had an ambiguously-defined spaaace.ash. I'll look into that.

Same could go for any similar search. You don't really want a /script getting matched with the /relay file.

Yes, you absolutely do. Since namespace uniqueness works like it does now, we -have- to enforce it globally. That means that if we didn't look for the script in /relay, then when we go ahead and drop it in /scripts we break both scripts silently.
 

Theraze

Active member
Ouch... that presents some nasty replacement issues for the future. Ah well, moving forwards and all that... guess that means I need to remove or rename the various scripts I have in the scripts folder that might now be auto-relay scripts in a dangerous sense. No more crimbo.ash type naming...
 

guyy

Member
It kinda creates a catch-22 thing, though, doesn't it? If the user has some script with a relay-script name, they can choose to not overwrite it (breaking the relay script) or to overwrite it (breaking both scripts because the relay browser doesn't seem to do a namespace search; even if it does search for it, the old /scripts script is gone).

If we really have to have uniqueness, a better option would be to rename the /scripts file when a conflict is found, which would only break things if it's a dependency for some other script. So, if something is supposed to go in /relay and it finds a file with the same name in /scripts, instead of overwriting it, rename the /scripts file and put the /relay file in the folder it's supposed to be in.
 
Last edited:

roippi

Developer
Renaming is something svn will not and will never do. Or support. If you rename a local file, it is deleting it as far as svn is concerned.

If I had my way I'd make relay/ not be in the script namespace, but I'm sure that would break a million scripts. So we're stuck with what we've got.

The best option is for non-relay scripts to not use names that could match a relay script name.

Correct.
 

guyy

Member
Renaming is something svn will not and will never do. Or support. If you rename a local file, it is deleting it as far as svn is concerned.

Only do that to non-SVN files, then? Making it think the file is gone without actually deleting it is the whole point of renaming it.

It's just kind of an annoying situation. As it is, unless the user renames any conflicting files manually, the relay script won't work and another script may get deleted. And the scriptwriter can't do anything about it (besides not installing through SVN at all) because the file causing the problem isn't theirs.
 

lostcalpolydude

Developer
Staff member
As it is, unless the user renames any conflicting files manually.

The expectation is that script users will have to rename poorly-named scripts to avoid conflicts. Unless you wrote the non-relay script to begin with, you can always at least redownload it from the forum. It may not be a completely smooth transition, but I'm confident the transition to non-conflicting names will happen.
 

roippi

Developer
r12247 addresses the issue that happened with delete: we used to short-circuit the namespace search if the file existed in its default location, but as the OP shows that can go wrong. So, cut that optimization.

Right now that file will simply be skipped, by delete as well as other svn operations. Other operations such as update will probably print a warning message, delete will fail silently, leaving both files; I should probably add a warning somewhere.

The issue with the popup message warning about the "original" path of the file rather than the "rebased" path still exists, so ticket is still open.
 
Last edited:
Top