Is allowing projects to serve without servePlaceIds a footgun?

[Kampfkarren]

We use servePlaceIds in Zombie Strike, as we have two places to update. It has been a life server, I cannot count the number of times I've almost synced the wrong place over (wrong port), but have been stopped by servePlaceIds.

However, sometimes I'll be working on a different project and accidentally sync in another one onto a place (has never happened over ZS thankfully)! This would've not happened had I used servePlaceIds.

This has me thinking--should projects without servePlaceIds be told to use them when they rojo serve? It could just be a warning if you want to quickly hack out a project, but it seems weird that something that has helped me so many times and was very easy to setup is probably seldom used.

Granted, a lot of the times I've messed up can be avoided if #211 is solved, but still want to throw this idea out there.

[sayhisam1]

Absolutely a footgun. I've got multiple rojo projects, and I have definitely accidently overwritten places with another rojo project.

I didn't even know this feature existed till I started browsing issues.

[LPGhatguy]

I'm not sure if the right approach is to unconditionally warn if servePlaceIds is not present. For projects that use rojo build along with rojo serve, Rojo is never connected to a live game and the warning might just end up noise.

In the future, I would like to have Rojo ask for confirmation before making changes to your place when initially connecting. This might alleviate the problem of syncing the wrong place in, since you'll be alerted pretty quickly that something is up!

[boatbomber]

We now have confirmation with diff visualization like LPG envisioned so syncing the wrong place is immediately obvious and cancelled with no damage done.