views:

154

answers:

2

I am running an svn project with optional components - pulling from several external repositories, and a number of users with varying access permissions to these externals.

The 'svn update' command aborts at the first project that it cannot retrieve.

Is there a better or standard methodology for svn:externals to allow successful checkouts for all users?

EDIT: I don't have ownership/control on the external projects to grant access, and mirroring the externals is not allowed by company policy. Because the externals are in support of optional components, users with fewer permissions will obviously not be maintaining the optional components. However, they will still need to check out other externals, and 'svn up' is very order-dependent.

I realize fixing permissions and splitting into sub-repositories will make this a non-issue, but I am still interested to know if there is any middle ground.

+2  A: 

What exactly do you want to happen if a user has access to a project, but not that project's externals? If the two are related strongly, then the user should have access to both. If the two aren't related strongly, then why are they being added as externals at all?

You could perhaps give each user readonly access to all the externals, and write access only to those who need it.

nickf
Good points; see edit.
HUAGHAGUAH
+1  A: 

If this is a sufficiently huge problem, you could restructure your workspace so that you have a top level that consists just of externals references to the parts of the projects. Then have different people use different top-levels to get the externals they need.

Needs a lot of management and thought tho.

Something like:

/Projects
 /Project1
  /trunk
 /Project2External
  /tag1
/Workspaces
 /Project1
  /DevA - svn:external Project1/trunk Project2/tag1
  /DevB - svn:external Project1/trunk

But you'd have to be willing to restructure the project this way, and think about what to do when there's global changes to the externals. But, in this way, you'd still be working on the trunk of project1, so there's no additional fiddling around.

Jim T