SVN e Visual FoxPro Databases

Question

Alguém já experimentou incluindo Visual FoxPro Databases (ver 7) no SVN? Quais foram as vantagens / desvantagens de incluí-lo em? Qual é a melhor abordagem para lidar com VFP Db em SCM quando há linhas que precisa ser incluído no controle de origem?

Answer 1

Christof Wollenhaupt tem uma ferramenta chamada "TwoFox" que faz um bom trabalho convertendo DBCS e outros arquivos de origem Fox para XML - o artigo descrevendo é http://www.foxpert.com/docs/cvs.en.htm . Se você está apenas perguntando sobre soltando os arquivos DBF no SVN, porém, você pode importá-los como arquivos binários, e perdem a capacidade de comparar / merge entre as versões, ou o uso CURSORTOXML (que estava no 7, não era?) para converter os DBFs para XML antes de verificar-los.

Answer 2

Enquanto eu não usei SVN, eu usei VFP tanto com VSS e Vault. Com esses dois, eu adicionar manualmente arquivos para controle de origem, em vez de tentar usar alguma forma de integração dentro do ambiente Dev.

Existem basicamente duas maneiras que você poderia abordar esta questão:

1. Basta adicionar manualmente o .DBC, .dct, .DCX e todo o DBF, .FPT e .CDX
2. Escreva um script do banco de dados para criar a estrutura (eu uso uma versão modificada do GenDBCX), ea criação de script de todos os registros de dados que deseja preservar em um programa ou classe.

Answer 3

Minha configuração:

---

• Windows XPSP3 como uma máquina virtual, em execução:
  • VFP 8
  • TortoiseSVN
  • SCX para converter todos os "arquivos de objeto" em texto simples arquivos .

---

• Debian em uma estação de trabalho P4, em execução:
  • Subverison via Apache2
  • Trac com ganchos em Subversion
  • backups noturnos regulares de ambos Subversion e o banco de dados Trac

---

Francamente, eu não verificar nas bases de dados multi-megabyte que temos porque o repositório iria inchar a cerca de 20 + Gbyte em tamanho desde que sozinho. Nós regularmente têm mesas 1,6 GB (e seus memorandos e índices) e é apenas não vale a pena as horas perdidas à espera de um 1 hora-plus comprometer em 20Gbytes de alterações da tabela. Em vez disso, nós clonar os dados do nosso sistema de produção e usar isso para as coisas "refresh", e reconstruir a nossa contêiner banco de dados ter ligações frescas para as tabelas. O processo de "atualização" é feito uma vez por mês e leva muito menos tempo, geralmente 40 minutos; Compare isso com horas desperdiçando todos os dias .

Eu não tive a necessidade de check-in de dados para o repositório, sequer uma vez. gerenciamento de esquema foi simplificado, seguindo uma regra única por enquanto: apenas dados refrescar depois de todos os patches destinados para produção foram empurrados para a produção, o que implica o esquema para ambos os ambientes serão consistentes. Por agora, eu posso ir longe com isso, embora isso vai ter que mudar no futuro ...

Se você só precisa de alterações de esquema

Se você achar que você está precisando de check-in mesas porque você está tentando capturar sua esquema e não necessariamente o dados que eles contêm, você pode querer olhar para escrever uma pequena ferramenta que bombeia para fora o esquema em um arquivo de texto e cometer que a repo, em vez de enviar a pia da cozinha fora para ser digerida.

Se é absolutamente necessário para o check-in de dados

Se houver dados nas tabelas que é fundamental para controlar o fluxo de programa (dados-como-código, e não apenas dados que são processados ??pelo programa), você pode considerar aparar os seus dados para o mínimo necessário e check-in apenas as tabelas stub resultantes , adicionando-os manualmente para o repo. Enquanto subversão irá lidar com objetos binários, você vai querer mantê-los a um tamanho mínimo e cometê-los tão pouco quanto possível, de modo que a sua repo não atolar. Certifique-se de verificar nas tabelas individuais que você está depois, e não apenas todos .dbf *, ou você pode ser dentro para um choque rude quando alguém tentar empurrar vários gigabytes de dados em seu repo porque a cópia de trabalho não mascarar todas as tabelas.