Diferentes sistemas distribuídos de controle de versão trabalhando juntos

Question

Meu escritório tem uma instalação central do Source Safe 2005 que usamos para controle de origem.Não posso alterar o que o escritório usa no servidor.

Eu desenvolvo em um laptop e gostaria de ter um repositório de controle de origem local diferente que possa sincronizar com o servidor central (quando disponível), independentemente de qual seja esse provedor central.O motivo da solicitação é para que eu possa manter uma ramificação/construção local estável para apresentações de clientes enquanto continuo a desenvolver sem ter que passar por obstáculos em chamas.Além disso, como consultor, meus clientes podem solicitar que eu use seu provedor de controle de origem e a flexibilidade aqui tornaria a vida mais fácil.

Algum dos clientes de controle de origem distribuído existentes pode lidar com isso?

Answer 1

Bem...KernelTrap tem algo sobre isso.Parece que você pode usar vss2svn para canalizar o repositório Source Safe para um repositório Subversion e, em seguida, use o ótimo git-svn para entrar em um repositório git local.

Eu presumiria que os commits de volta ao VSS não seriam um processo automático e tranquilo usando esse método.

Answer 2

Você deve ser capaz de verificar a versão atual do código e criar um repositório git em torno dele.Atualizar isso e enviá-lo para seu repositório git local deve ser fácil.Assim como cloná-lo.

O único problema é que você precisa fazer com que ambos se ignorem (fiz algo semelhante com o SVN) mexendo nos arquivos ignorados apropriados.Presumo que o SourceSafe permite que você ignore as coisas.E você precisará executar determinadas operações duas vezes (como informar a ambos que está excluindo um arquivo).

Answer 3

Esse O episódio de HanselMinutes cobre exatamente o que eu esperava ouvir.Aparentemente, o Git pode ser usado localmente e depois anexado a repositórios subversion/vss externos conforme necessário.Eles falam sobre isso entre 14 e 15 minutos.

Answer 4

algum dia trabalho em uma empresa que usa VSS (e em outras empresas que usam outros menos desconhecidos SCM), mas prefiro usar SVN (algum dia tentarei o GIT) para desenvolvimento ativo, para mim e meu grupo.

Em primeiro lugar, esta situação é apenas uma boa ideia, se os compromissos com o VSS forem poucos ao longo do mês, porque trabalhar com outro SCM (que não o VSS) oferece mais flexibilidade, mas o compromisso com o VSS do SVN é caro no tempo.

Minha solução foi:

VSS -> SVN:Eu tenho um script Linux (ou script ant ou script XXX) que copia do trabalho do diretório de atualização atual do VSS para o SVN atual, depois atualiza o cliente SVN e atualiza/mescla/compromete-se com o SVN.Com isso, você fica atualizado com as mudanças do restante da empresa que utiliza VSS.

SVN -> VSS:Dessa forma, você precisa fazer o check-out de todos os seus arquivos de modificação para o VSS, então você pode simplesmente usar o script reverso para copiar do diretório SVN de atualização atual (ignorar os diretórios .svn) e copiar para o diretório VSS de atualização atual, atualizar e confirmar.

Mas lembre-se, em alguns casos vale a pena dedicar seu tempo para fazer isso.