É possível importar um repositório MKS Integrity em git?

StackOverflow https://stackoverflow.com/questions/1314218

Pergunta

Eu preciso somente a árvore de origem e sua história. Eu não ligo para as coisas requisitos / questões por agora. Joguei um pouco witth da linha de comando para descobrir se eu poderia obter uma lista de pacotes de mudança para o tronco e alguns dos caminhos dev. Eu pensei que deveria ser possível extrair um diff para cada pacote de mudança e usar isso para reproduzir todas as mudanças desde o primeiro cometer no git. Algo parecido com isto:

  1. começar primeiro cometer e adicioná-lo à git
  2. começar no próximo CP
  3. get diff para CP
  4. se candidatar diff de trabalho git dir
  5. adicionar e submeter alterações git
  6. repita com (2) até o último CP

Você também pode pacote mudança repleace com checkpoint (seria bom o suficiente para mim).

A maneira mais simples seria apenas para check-out a CP e adicionar / comprometer com git. Mas então você perderia o controle de operações de adicionar, remover, mover e renomear.

Alguém sabe como conseguir um diff unificado de "si diff"? Isso já ajudaria muito.

Todas as idéias?

Edit2:
Adicionado uma resposta que mostra como eu realmente fiz a migração ...

Foi útil?

Solução

O problema com MKS Integrity é seu repositório único em que tudo reside:

  • requisitos,
  • planos de teste,
  • casos de teste,
  • características,
  • tarefas do desenvolvedor,
  • pedidos de implementação

Uma vez que esses dados podem evoluir de forma independente um do outro, em seu próprio ritmo, importá-los todos em um repositório Git seria uma má idéia: você só pode clone todas o conteúdo de um repositório Git ( mesmo se você pode limitar a profundidade desse clone).
Isso significa que você vai ter todos os documentos, mesmo que você está apenas interessado no código.
Uma exportação MKS Integrity implicaria definir primeiro muitos repositórios Git para atuar como submódulos .

Eu preciso somente a árvore de origem e sua história.

Como de costume, eu recomendaria apenas a importação:

  • as grandes gravadoras (para qualquer coisa mais de um ano, ou seja o período que você se sinta confortável que você não vai precisar do exame na íntegra, porque é tão velho)
  • todos os rótulos (grandes e menores) durante os últimos anos.

E eu não importar tudo em um repositório Git a menos que você está confiante de que todas as suas fontes representa um sistema desenvolvido como um todo (e não vários "módulos" desenvolvido independentemente)

A maneira mais simples seria apenas para check-out a CP e adicionar / comprometer com git.

Essa seria a maneira de proceder.

Mas então você perderia o controle de operações de adicionar, remover, mover e renomear.

Não! Você não faria! Git irá inferir essas operações .
Essa é a vantagem de ser um arquivo conteúdo VCS .

Outras dicas

Eu não posso postar o programa real que eu escrevi, porque não fazê-lo em meu próprio tempo. No entanto, eu posso postar como eu fiz isso. Deve ser fácil para refazer-lo com qualquer linguagem de script. A ferramenta que eu escrevi migraram apenas um ramo de cada vez. Eu diria a ele que se ramificam eu quero (por exemplo, 1.21.1) ea revisão começando e terminando no ramo (por exemplo, 4 e 78 migrariam todas as revisões a partir de 1.21.1.4 até 1.21.1.78). Para ter todos os ramos em um repo que eu iria fornecer o diretório .git para uso para importar para.

  • começar circuito de iniciar a revisão para acabar com a revisão
    • CURRENTREV = BRANCH.loopcounter
    • criar o diretório repo
    • mover a dir .git para o diretório repo
    • mover o arquivo .gitignore no diretório repo
    • chdir para o diretório repo
    • criar MKS sandbox dentro do repo dir via "si createsandbox -P MKS_PROJECT_PATH --yes --projectRevision = CURRENTREV
    • buscar descrição revisão via! "Si viewprojecthistory --rfilter = intervalo: CURRENTREV-CURRENTREV", saída de captura
    • extrato de usuário, data, etiqueta (s), comentários de saída anterior
    • "add git".
    • tubo extraído informações acima em "git commit -qf -" (não pode fazer -m se você quiser várias linhas como o comentário checkpoint)
    • sandbox gota via "si dropsandbox --yes index.pj"
    • move .git e .gitignore a um save lugar (para a próxima iteração)
    • apagar todos os arquivos restantes no diretório sandbox
    • Mover para dir pai (..)
    • sandbox de exclusão / repo dir
  • criar git dir
    • última
  • move .git e .gitignore em git final, dir
  • "git reset CABEÇA --hard"

Feito.

MKS usa algum tipo de codificação ASCII para a sua corda e git normalmente usa UTF-8 por isso esteja atento para o problema ao importar dados de meta em git (nomes de usuário, comentários, tags, etc.).

Para mais ramos fazer isso:

  • no diretório git checkout da revisão onde o ramo deve começar e criar uma filial ( "git checkout -b NEWBRANCHNAME")
  • agora passar .git e .gitignore ao salvar local e apagar toda a dir
  • agora fazer a mesma coisa como acima

Mais uma coisa: "si" é a ferramenta de linha de comando MKS. Então você quer necessidade de especificar o caminho completo ou colocar o seu caminho para o caminho de pesquisa.

FWIW, diff si, infelizmente, não suporta atualmente diff unificado. Há um pedido de mudança para tê-lo fazê-lo, mas ainda não foram muitos clientes que pedem esse recurso.

IMPORTANTE:. Trabalho I para PTC (que adquiriu MKS)

Isso funciona para checkpoints ...

https://gist.github.com/2369049

Infelizmente, checkpoints são aparentemente a única coisa que realmente faz qualquer sentido de MKS -> GIT, como um ponto de verificação é realmente a coisa mais próxima do "instantâneo", que GIT chama de cometer.

MKS tem tantos conceitos incompatíveis (por versão de rastreamento de arquivo, filiais que não são nada como ramos GIT, pontos de verificação, etc.) que podem evoluir de forma independente um do outro, é realmente difícil dizer como migrar uma história sensível em GIT . Existem provavelmente muitas maneiras de fazer isso e nenhum deles mais "correta" do que o outro.

Dito isso, eu adoraria ouvir algumas boas idéias. :)

Eu adoraria ver uma solução que captura o por arquivo de versões de uma forma sensata. Em algumas discussões que têm jogado em torno da idéia de tentar alinhar MKS versões por arquivo por comprometer-time ou algo assim. Dessa forma, podemos formular o conceito de "repo" evoluindo através de uma confirmação que contém alterações em vários arquivos.

Eu uso essa ferramenta para pacotes de mudança de importação de MKS em Mercurial, importá-lo para git deve ser bastante similar; ou você pode importar para Mercurial primeiro lugar, e usar a ferramenta git para importar Mercurial seguinte.

https://github.com/arsane/py-mks2hg.git

Ele vai tentar descobrir todos os pacotes a mudança que no âmbito do projecto especificado, e comprometer-se novo repositório Mercurial em ordem.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top