mike...
if i understand your issue, regardless of what choice you make, the projects
have the potential to deviate from each other as they go forth....
i'd opt for a third choice. make separate repositories... however, i'd put
together some sort of reporting mechanism (if possible) that more or less
tracks the diffs between the repositories. (you might actually want to keep
a 3rd repository that periodically sucks in the work from the two separate
repositories..)
i'd make sure that the guys/resources with the decision making authority
unuderstand how the projects are deviating over time, and that they have a
pretty good understanding of the costs involved to re-merge as time goes
on...
other than that.. there's not much you can do.
have fun...
-----Original Message-----
From: Mike [mailto:mikedl@comcast.net]
Sent: Friday, August 27, 2004 10:38 AM
To: users@subversion.tigris.org
Subject: Restricting repository branch access
Hi. I have a problem and hope someone can give me a suggestion.
I administer a svn repository (accessed via svn+ssh only) for two projects
which are each derivations of a single original codebase. When the projects
were started up, the idea was for them to be able to exchange improvements,
so I implemented the projects as subversion branches, and this has served us
well.
Due to corporate decisions several levels up the tree, the staff on branch A
is no longer allowed to see any of the work on branch B.
So I have to figure out how to implement this quickly (the server is off the
air until I figure out something). I see two options and am looking for
comments or other suggestions.
1. Use svnadmin dump and svndumpfilter to create a separate repository for
staff A that has no branch B. The disadvantage is that if the decision is
changed in the future, it will be hard to "remerge" the projects.
2. Setup for http access and use the http access controls (I found an email
suggesting that I can limit branch access using webdav). The (huge)
disadvantage here is that I will need to setup this new access method and
retrain all the developers to use it.
Thanks for any advice!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 27 20:13:55 2004