[FUG-BR] subversion solucao para atributos especiais

[Patrick Tracanelli]

Evandro Nunes escreveu:
> era bem isso que eu queria
> voces prestam consultoria em svn?
> esta em freebsd inclusive usei o seu pdf de referencia
> e voce acertou é sim itil
> 
> outra coisa tem como dividir a arvore do repo em labels e
> garantir que um label so so pode ser alterado com a autorizacao
> de alguem responsavel por aquele trecho da arvore?

Ola,

Prestamos sim, serviço completo em SubVersion, referência:

http://www.freebsdbrasil.com.br/home.php?area=2&conteudo=8&sub=81

Legal, aquele PDF tem um número impressionante de downloads. Devo 
publicar uma revisao dele em breve com algumas coisas q mudaram desde q 
foi escrito.

Tem sim, como fazer isso que voce quer tambem. Podemos criar um arquivo 
de controle no melhor estilo que o Projeto FreeBSD tem como MAINTAINERS 
e nele listar a estrutura e cada mantenedor e criar um processo que eu 
gosto muito, chama-se de quarentena de commit. Nesse caso um novo commit 
fica sem ser efetivado até o aval do mantenedor e no repositório o 
arquivo fica locked.

> 
> 2009/2/11 Patrick Tracanelli <eksffa em freebsdbrasil.com.br>:
>> Hmm, ja vi tudo. ITIL sendo implantado e o Repositório vai ter que
>> acumular funções, certo?
>>
>> É completamente possível. Subversion tem um recurso chamado
>> propriedades, a ideiaa é usar e abusar disso. É como se fossem atributos
>> customizados na árvore SVN.
>>
>> Pensemos numa estratégia simples
>>
>> Pense nas propriedades:
>>
>> itil:limitcommit = 5000
>>
>> itil:commiters = patrick, joao, maria
>>
>> itil:versaoatual = $REV$
>>
>> E propeidades adicionais:
>>
>> itil:crisiscode
>> itil:incidentid
>>
>> Com isso em mente, voce vai programar hooks, que podem ser de
>> pre-commit, e nesses hooks voce vai programar
>>
>> - Se quem está fazendo commit estiver listado em itil:commiters, verifica:
>>
>> - Se o conteudo de itil:versaoatual for menor que itil:limitcommit todos
>> podem fazer commit a vontade. Senão, o usuário listado em itil:commiters
>> não pode fazer commit, e voce da um exit com o código que desejar dentro
>> do esperado pelo SVN.
>>
>> - Para todo e qualquer usuário, verifique se itil:crisiscode existe e
>> também se itil:incidentid existe. Se não existir não permite o commit.
>> Se existir você racionaliza, ve se o conteudo de itil:crisicode faz
>> sentido (exemplo, apenas números), e se itil:incidentid faz sentido -
>> comparando com o formato de identificadores de incidente que a sua
>> gerencia de incidentes utiliza.
>>
>> Pra melhor, automatize. Sua gestão de incidentes deve ter o mesmo
>> crisiscode e incientid em algum banco de dados onde eles controam isso.
>> Pesquise nesse banco! Afinal não pode haver um commit motivado por
>> incidente se o incidente não estiver registrado certo?
>>
>> O SVN utiliza hooks no diretório hooks/ de cada repositório. Nele voce
>> pode criar rotinas na sua linguagem favorita (shell, perl, php, python,
>> awk, sed, forth, fortran hehe), e o SVN executará o hook em questão.
>>
>> Nos podemos fazer isso.
>>
>> E possivelmente tudo o mais que seja possivel fazer no SVN. Creio que
>> poucos sistema de versionamento sao flexiveis como o SVN.
>>
>> Que eu conheça só Perforce é mais.
>>
>> Evandro Nunes escreveu:
>>> lista
>>>
>>> tenho uma demanda para criar restricao de acesso a alguns arquivos no
>>> repositorio
>>> quando eles passarem de uma certa versao que combine com a versao
>>> limite configurada
>>>
>>> por exemplo tenho um arquivo em trunk/4.0/sw/vi.jsp
>>>
>>> nesse arquivo quero gravar uma informacao, uma marcacao de versao, por
>>> exemplo versao X
>>>
>>> quero permitir que um certo (ou certos) usuario possa fazer commit
>>> nesse arquivo ate a versao X
>>>
>>> se o repositorio passar da versao X quero que aquele usuario nao possa
>>> mais fazer commit apenas checkput update e outras coisas de leitura
>>>
>>> quero ainda que o nome do usuario que fez a ultima alteracao sempre
>>> seja preenchido com argumento
>>> que e o codigo interno de chamado de problema, chamado de crisis-code
>>> e tambem do numero do chamado como aberto
>>> pelo povo da gestao de incidentes
>>>
>>> quero que nao possa acontecer commit nesses arquivos sem esses dados preenchidos
>>>
>>> mas como essas informacoes sao especiais nao podem logicamente estar
>>> nos logs de commit
>>>
>>> preciso saber se tem como fazer isso
>>> se tiver como fazer preciso de uma visao sobre isso, uma visao da ideia
>>> e por ultimo se for muito chato preciso saber quem pode fazer isso e
>>> outras peripecias mais
>>> -------------------------
>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
>> --
>> Patrick Tracanelli
>>
>> FreeBSD Brasil LTDA.
>> Tel.: (31) 3516-0800
>> 316601 em sip.freebsdbrasil.com.br
>> http://www.freebsdbrasil.com.br
>> "Long live Hanin Elias, Kim Deal!"
>>
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


http://www.freebsdbrasil.com.br/home.php?area=2&conteudo=8&sub=81

-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"