Configurando o acesso SVN com o servidor Subversion

2

Fundo rápido. Estamos executando o Subversion Server 1.6.5 (Não há Apache apenas o servidor SVN) em uma caixa do Windows sem acesso à web. Nós só usamos TortoiseSVN e AnkhSVN e para integração contínua usamos a linha de comando do cliente svn.

OK, então eu dei uma olhada no NET e li o livro SVN um pouco e não entendi porque essa configuração de usuário não funciona.

conteúdo authz (arquivo de autorização SVN):

    ### Sanitized version
    [groups]
    devUsers = user1
    qaUsers = user2

    [/]
    @devUsers = r
    @qaUsers = r

    [/Dev/SourceCode]
    @devUsers = rw
    ~devUsers = 

    ### QA Projects
    [/Dev/testCases]
    @qaUsers = rw
    ~qaUsers =

Pelo que eu li, você precisa conceder a todos os usuários, no mínimo, acesso de leitura à raiz do seu repositório. OK, tudo bem. Isso funciona. Em seguida, o meu diretório / Dev / SourceCode só deve ser acessível para @devUsers, mas por algum motivo no repo-browser do TortoiseSVN, @qaUsers pode ver esta pasta. Eu estou supondo que o acesso de leitura global em / está substituindo a linha ~devUsers = no arquivo authz? E o mesmo vale para a pasta / Dev / TestCases que deve ser acessível apenas para @qaUsers , mas @devUsers também pode ver essa pasta. Esse é um dos meus problemas.

O problema principal é que as subpastas / Dev / SourceCode são somente de leitura. Eu sei disso porque quando eu tento fazer o check-in de algo em uma subpasta, diz que a autorização falhou. No entanto, na pasta raiz, se você fizer o check-in de um arquivo, funcionará bem.

Suponho que esse é o acesso somente leitura / que sobrepõe as coisas novamente. Isso significa que cada subpasta precisa receber permissões explícitas de rw? Existe alguma maneira de dizer a partir deste ponto em usar as permissões da pasta pai atual ?, ou seja, as permissões de / Dev / SourceCode. Isso parece muito inconveniente se você quiser conceder permissões de rw para todas as subpastas quando houver muitas subpastas.

    
por nickytonline 27.07.2010 / 03:45

3 respostas

0

Meu pensamento inicial ao ver seu arquivo de autorização era "os nomes do repositório não estão ausentes das declarações de caminho?"

Com isso quero dizer,

[/Dev/SourceCode]
@devUsers = rw
@qaUsers = 

deve ser parecido com

[<repo-name>:/Dev/SourceCode]
@devUsers = rw
@qaUsers = 

ou, se 'Dev' for o nome do repositório,

[Dev:/SourceCode]
@devUsers = rw
@qaUsers = 

Eu uso o apache para nossos repositórios, mas a sintaxe é a mesma, seja httpd ou svnserve: Autorização Baseada em Caminho

Espero que isso ajude.

Obrigado,
Zachary

    
por 05.08.2010 / 19:47
2

A cascata de permissões deve funcionar conforme o esperado; não há necessidade de permissões em todos os dir. Você só precisa especificar os caminhos mais específicos para substituir as permissões do pai, como você está fazendo.

Não estou familiarizado com a sintaxe ~groupname . Você está claramente pretendendo que signifique negação (usuários que não estão no grupo), mas não tenho certeza se é compatível. Tente algo assim (suas duas primeiras seções para defs de grupo e acesso root são as mesmas):

[/Dev/SourceCode]
@devUsers = rw
@qaUsers = 

[/Dev/testCases]
@qaUsers = rw
@devUsers =

Isso deve funcionar, embora negar o acesso de seus desenvolvedores aos casos de teste me deixa triste.

EDIT: Desde que você tentou isso, e não funciona ... talvez tentar reverter o pedido? A correspondência deve acontecer da mais específica para a menos específica, portanto, a ordem não deve importar, mas pelo menos eu tentaria colocá-las mais cedo no arquivo do que as permissões [/]. Se isso fizer diferença, suspeitaria de um bug na sua versão do servidor.

    
por 27.07.2010 / 08:57
0

Idéias totalmente separadas da minha outra resposta:

... tem certeza de que não há um erro de digitação (por exemplo, caso) na sua definição [/ Dev / testCases]? (Você está no Windows: Eu sei que o Windows mostrará coisas como 'Dev' se elas forem chamadas 'DEV', por exemplo ... mas o SVN provavelmente vai se importar)

... também, tem certeza de que não deveria ser [/ trunk / Dev / testCases] ou algo assim?

    
por 28.07.2010 / 06:28