Setting Up SVN for Atomic Commits and Restricted Access

We're having a discussion at work currently and I was looking for some advice on SVN setup.

Our pattern is that we have a variety of projects checked into SVN, some of these projects depend on others. For example FooWebServices depends on FooCommons.

In the case where I'm working on a feature that requires changes in FooWebServices and FooCommons I want to be able to do an atomic commit across those two projects. If I've screwed up somehow and the commit fails for FooWebServices the whole ball of wax fails. That way I'm not screwing up any other devs or having to go back out changes while I track down whatever issue I had. The CI server also seems to开发者_如何学Go be getting confused pretty frequently.

I can do a shallow checkout of the root (then FooWebServices and FooCommons under that) of our repo and get this behavior. Then I can get that atomic commit behavior.

The situation is complicated in that we have contractors also working in the repository. Currently they cannot check out a shallow copy of root so they can't get that behavior.

I'd like to set things up so that the contractors can check out root, FooWebServices, and FooCommons, and nothing else. I'd also like to prevent them from browsing root to seeing the projects we haven't granted them access to.

Is this possible? Am I overcomplicating the problem and atomic commits aren't even necessary?

I think it's too complicated - AND coupled.

You should not have a bi-directional relationship; if you do, you've got bigger problems. (They really are just one project in that case.)

Cycles should be avoided. Break them up with well-placed interfaces.

A better approach for related projects might be to have a one-way dependency. If project A depends on B you can work on project B, commit changes, then create a JAR file that's added to project A.

The beauty of this approach is that changes to A need not force a deployment of B; it can accept changes to A when it can by continuing to use the old JAR until the time is right to upgrade.