[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: TortoiseSVN import similar to TortoiseCVS make new module?

From: Andy Levy <andy.levy_at_gmail.com>
Date: 2007-11-27 18:17:30 CET

On Nov 27, 2007 12:09 PM, Eric White <ewhite@ssc.wisc.edu> wrote:
> Hello,
>
> I've used CVS and the TortoiseCVS client for years and I'm just moving over
> to subversion with TortoiseSVN. I wanted to run my thoughts by the list and
> see if I'm understanding things correctly.
>
> I've got two groups of developers who work on different sets of projects.
> I'm thinking of arranging my repositories like this:
>
> /developer_group_1
> /project_1
> /trunk
> /branch
> /project_2
> /trunk
> /branch
> /project_3
> /trunk
> /branch
>
> /developer_group_2
> /project_A
> /trunk
> /branch
> /project_B
> /trunk
> /branch
>
> So as long as I created the "developer_group_1" and "developer_group_2"
> repositories, the developers in group 1 could use the import command on the
> TortoiseSVN client to import files to "project_1", etc, while developers in
> group 2 can do the same in their repository. I believe this would be
> similar to our current method of developers creating a new module and then
> committing in CVS.
>
> I'm thinking of using 2 repositories because the developers in each group
> should not have rights to access the files of the other group. Does this
> seem sensible?

You don't need 2 repositories. See the Subversion manual's sections on
server config, especially path-based authorization. Deny access to
developer_group_1 for the people in group 2, and vice versa.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Tue Nov 27 18:17:36 2007

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.