LSCSRoot on a shared server?

Adam Stoller

Environment[indent]TS/OD/LS 7.2.1 on Linux[/indent]Scenario[indent](Note: I was not involved with the original setup - just trying to make sure things are configured correctly, or, whether I have to push back and get something changed)
The customer has two TeamSite environments:

Comments? Not about whether it's "good" or "bad" from a general perspective, but whether works as-is correctly, or is broken and they just haven't realized it yet.In the latter case, I want to know whether my guess at a low-cost fix (distinct target directories) is sufficient, or whether there really isn't any choice other than standing up another set of servers with new licenses.

Rick Poulin

Would the fact that the fully qualified vpaths of the source files containing the source sever name be sufficient to prevent clobbering and/or bleeding through of the files from DEV_TS from those of PROD_TS and vice-versa?

I think I pulled out the initial question in there..

The answer to this is that yes, it's sufficient. The full (w/server) vpath is what is used to create an LSCS repository. Thus, //foo/default/main/hello and //bar/default/main/hello is just as segregated as the former and //foo/default/main/world. You're quite safe in that regard (I've actually encountered much pain when one day my LSCS deployments decided to use //localhost instead of //hostname...)

The one weird case I can think of is if, during the course of a content migration of some kind, you copy a default.site across environments. The server-qualified branch path to the default.site file is hardcoded inside this file and this is what is used by default to determine which LSCS repository/project your components query. This property only ever gets refreshed if you edit and re-save the default.site file through SitePub. Thus, if you just copy it without doing anything else, you might accidentally be looking at the DEV repository/project even though your site is being rendered by your TEST runtime.