We are in a place in our project timeline where we can finally migrate to utilizing the new native SVN integration offered in PB2017 (specifically R3, LTS).  I've run into a few confusing setup requirements and trying to get clarification as to the intended approach.

When adding to source control, if I stage the workspace, target and application PBLs inside a current SVN checkout of the repository, it fails adding the files with an SVN error "... is already a working copy for a different URL".  The PB commit process doesn't see that the current folder is already a local checkout of the repository.

If I move the raw workspace to a folder outside the SVN checkout location, I'm able to initially add the workspace and files to source control.  I can SVN update from the original SVN checkout folder and get the newly committed workspace.  If I try to open the PB workspace from this location, I can open it using "Connect to Workspace" but none of the objects under PBLs are connected to their source.  

In nearly all other IDE environments, using GIT, SVN, or others, you can work directly on the local working copy of a repository.  It seems with PB native SVN, I can only do this if I start by connecting to the workspace from an external, dedicated location.  Is this intended?  Is this a bug, "not being able to deal with a checkout from a larger parent SVN working copy"?

Bear in mind that we work on a large enterprise system repository with multiple branches and many applications and components within the repository.  Having to handle PB in a separate structure is not ideal.

Thoughts and guidance appreciated!

-Ryan Creps