2017-06-15 3 views
2

Ich führe eine Reihe von Python-Skripten aus, die alle Teile desselben (großen) Frameworks verwenden. Ich verwende verschiedene Versionen dieses Frameworks, alle unter Versionskontrolle und da jeder Test verschiedene Teile davon verwendet, habe ich beschlossen, dass es schneller ist, nur die Teile zu checken, die ich brauche. Mit anderen Worten, ich hatte erwartet, sparse Checkouts zu verwenden. Meine Absicht ist es, Schritt für Schritt eine leere Arbeitskopie auszuprobieren und per Update zu aktualisieren, um das (fast) vollständige Framework im Laufe der Zeit zu sammeln. Ich benutze ein Python-Skript mit Modulfinder, um zu entscheiden, welche Teile des Frameworks ich für jedes Projekt brauche. So erhalten folgende I:svn checkout/update ohne existierende (versionierte) Dateien auf der Platte zu löschen

Projekt Foo, Rahmen Baum:

\R100 
    \Framework 
    \Module_1 
     \Submodule_1 
     \Submodule_5 
    \Module_2 
    \Module_3 

Checkout-Routine:

svn checkout repo.url/[email protected] local\R100\Framework --depth empty 
svn update \local\R100\Framework --depth immediates --revision 100 
svn update \local\R100\Framework\Module_1 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_1\Submodule_1 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_1\Submodule_5 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_2 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_3 --depth immediates --revision 100 

Projektleiste:

\R100 
    \Framework 
    \Module_1 
     \Submodule_1 
     \Submodule_2 
    \Module_2 
    \Module_3 

Checkout-Routine:

svn checkout repo.url/[email protected] local\R100\Framework --depth empty 
svn update \local\R100\Framework --depth immediates --revision 100 
svn update \local\R100\Framework\Module_1 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_1\Submodule_1 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_1\Submodule_2 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_2 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_3 --depth immediates --revision 100 
Moo

Projekt:

\R100 
    \Framework 
    \Module_1 
     \Submodule_1 
     \Submodule_3 
    \Module_6 
    \Module_9 

Checkout-Routine:

svn checkout repo.url/[email protected] local\R100\Framework --depth empty 
svn update \local\R100\Framework --depth immediates --revision 100 
svn update \local\R100\Framework\Module_1 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_1\Submodule_1 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_1\Submodule_3 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_6 --depth immediates --revision 100 
svn update \local\R100\Framework\Module_9 --depth immediates --revision 100 

Das Problem ist, jedes Mal in Folge Update beginnt mit dem Löschen der bereits vorhandenen Dateien statt Check-out nur die neu in diese Arbeitskopie-Dateien . Gibt es einen Weg, das zu überwinden? Ich realisiere Einstellung update/checkout Tiefe ist der Grund, aber ich möchte dies überwinden sagen dem Svn-Client "Gut, diese Dateien und Ordner sind nicht mehr im Rahmen der Kasse, aber da sie schon hier sind, behalten Sie sie trotzdem"

Antwort

0

Die Herangehensweise, der Sie folgen wollten, wird nicht gut funktionieren und ich erwarte eine Menge Schmerzen mit einer solchen Arbeitskopie. SVN bietet Werkzeuge, die für solche Fälle entwickelt wurden.

Es scheint mir, dass Sie insbesondere vendor branches oder svn:externals fehlen. Sie könnten eine dieser Funktionen oder beide im SVN-Repository erforschen und implementieren:

  • Verwenden vendor branches zu halten maßgeschneiderte Codebasis auf externen Code abhängig.
  • Verwenden Sie svn:externals mit Tags in SVN, um eine Arbeitskopie aus mehreren Projekten oder Auschecken zu erstellen.
Verwandte Themen