Discussão:Sistema de controle de versões

Paabéns pelo artigo! Glum^responder 21:15, 14 Junho 2006 (UTC)

SCM

SCM pelos documentos da IEEE é [Software Configuration Management]. Creio que não seja ideal usá-lo no artigo, ou senão, usá-lo em um outro tópico, fora do principal.

Os mais comuns...

Não tenho acesso a estatísticas relevantes, mas na minha experiência, os mais comuns são CVS e ClearCase. SVN é mais comum apenas se se considerarmos somente software livre/aberto. Vou modificar a frase de forma a ser menos restritivo nesse aspecto (entre os mais comuns encontam-se...) —o comentário precedente não foi assinado por Girino (discussão • contrib.) 12:22, 20 Setembro 2006 (UTC).

Tudo bem, a frase ficou até melhor, mas creio que você esteja bastante equivocado. Em todas as empresas que passei até agora, só utilizavam SVN e CVS. Nunca nem ouvi falar do ClearCase, e tenho mais de 10 anos de experiência no mercado e na área de software. LipeFML_ 12:22, 20 Setembro 2006 (UTC)

Vou tentar fazer mais pesquisas a respeito, mas existem muitas empresas que não aceitam o uso de software livre, e estas optam por um dos grandes fornecedores... Tenho 8 anos de experiência específica com gestão de configuração e já trabalhei em empresas que adotavam software livre (e dessas apenas uma usava svn e apenas em projetos menores) e empresas que não adotavam software livre. Nesse segundo grupo (cerca de 60% a 70% delas) apenas umas poucas usavam o Source Safe, as outras usavam o ClearCase. a estatística é mais ou menos assim:

software |	empresas no brasil |	empresas na europa |	empresas nos EUA |	orgãos governamentais do Brasil
CVS	1	1	1	1
SVN	1	0	0	0
SourceSafe	1	0	1	1
ClearCase	2	0	0	2

Claro que não representam o "todo", só as empresas onde já trabalhei (eliminando as que não usavam nada, que acho que era a maioria).

--girino 15:00, 20 Setembro 2006 (UTC)

É razoável. Mas minha experiência pessoal diz o seguinte:

software |	empresas no brasil |	empresas na europa |	empresas nos EUA |	orgãos governamentais do Brasil
CVS	2	-	1	-
SVN	4	-	2	-
SourceSafe	1	-	0	-
ClearCase	0	-	0	-

LipeFML_ 15:31, 20 Setembro 2006 (UTC)

Branch And Merge x Exclusive Lock

Como já disse antes, gostei muito do texto, ficou excelente. Só vejo um por: está descrito apenas o processo de controle de versão usando a filosofia "Branch and Merge" (o default do CVS e SVN), que diz qeu conflitos acontecem com pouca frequencia então é melhor que o usuário resolva manualmente os conflitos do que deixar arquivos "bloqueados" por muito tempo. Já as ferramentas comerciais, em sua maioria, usam a filosofia mais conservadora do "exclusive lock", onde um "checkout" num arquivo cria um "lock" naquele arquivo, que só é removido por um "checkin" (ou commit, na linguangem do CVS/SVN) ou um "release" (liberação do lock).

O processo de trabalh nesses sistemas é mais ou menos assim:

1. Get latest version (busca todos os arquivos e os mantem protegidos para escrita)
2. Checkout (cria o lock e dá permissão de escrita n oarquivo local)
3. edição do arquivo
4. checkin (cria nova versão e libera o lock).

Nessa filosfia, um merge ainda é possível, mas só pode ser feito depois de o detentor do lock liberá-lo:

1. A dá checkout
2. B tenta dar checkout e não consegue
   1. B dá checkout não reservado
3. B tenta dar checkin, mas não consegue, B fica aguardando A liberar o lock.
4. A dá checkin (ou release).
5. B dá um merge (que já cria um lock pra ele).
6. B dá checkin

--girino 22:37, 20 Setembro 2006 (UTC)

Obrigado Girino! Pensarei numa maneira de colocar isso no artigo. LipeFML_ 19:45, 28 Setembro 2006 (UTC)

Aliás, dei uma pesquisada rápida e o nome que encontrei foi "Optimistic Merges" ao invés de "Branch And Merge". LipeFML_ 19:48, 28 Setembro 2006 (UTC)

Problemas de "o desenvolvedor X nao deu um commit..."

Proponho a retirada do seguinte trecho acrescentado por anonimo, pois ele é uma "meia verdade":

“ Vale lembrar que sistemas que utilizam "Exclusive Lock" tem um problema inerente de sua arquitetura: se um desenvolvedor iniciar a edição de um documento e esquecer de executar um "commit" do documento, este estará bloqueado a outros desenvolvedores. Isto causa problemas como "o desenvolvedor X nao deu um commit no documento, e foi embora. Estou impossibilitado de editar este determinado documento até que ele retorne, e utilize o seu usuário e senha para desbloquear o conteúdo". ”

Em geral, isto só acontece em ambientes mal gerênciados, e os administradores (ou outros usuários com permissões especiais para o projeto) podem remover esses "locks", invalidando os checkouts dos desenvolvedores, caso seja necessário. Além disso, sempre se pode trabalhar de forma local, fazendo um merge depois (como na filosofia de mesclagens otimistas) quando o lock for liberado. Não vejo isso como um "problema na arquitetura" e sim como um "mau uso da ferramenta". Na minha opinião isso é um argumento de quem "não conhece a ferramenta" e acha que o ambiente em que está acostumado a trabalhar é melhor.

--girino 21:09, 29 Janeiro 2007 (UTC)

Concordo plenamente! --Lipe 2OO7 17:22, 3 Fevereiro 2007 (UTC)

Vocabulário; up-to-date

Parece que há um equivoco na definição do termo up-to-date, que na sessão vocabulário está traduzido como "Versão desatualizada"; pelo menos nas ferramentas cvs e svn, assim como nos seus front-end gráficos, e no livro do Cristiano Caetano (CVS - Controle de Versões e Desenvolvimento Colaborativo de Software; ed. Novatec, 2004), o termo "up-to-date" é definido e usado como uma indicação de que o arquivo mantido na área de trabalho é idêntico ao arquivo armazenado no repositório. --200.131.62.33 17h14min de 14 de Setembro de 2007 (UTC)

Obrigado pela correção, você está certo. Lipe λ _FML 13h45min de 15 de Setembro de 2007 (UTC)

Título

Em vez de "Sistema de controle de versão" deveria ser "Sistema de controle de versões". O uso de "versão" está incorrecto porque são várias versões e não uma.—comentário não assinado de Unit73e (discussão • contrib) 10h39min de 16 de agosto de 2016‎ (UTC)

Correto. Já fiz a moção do título da página. !Silent (discussão) 13h52min de 16 de agosto de 2016 (UTC)