SVN: Nur-Lese/Nur-Checkout-Datei

Question

Was ich suche, ist Folgendes:

Angenommen, ich habe eine Datei "database.conf", die einige Standardwerte für eine Datenbankverbindung enthält (dbname, user, password, etc). Jeder braucht diese Datei mit anderen Einstellungen (z.B. Passwort). Allerdings sollten die lokalen Änderungen an dieser Datei nicht in das Repository übertragen werden. Die Datei sollte also sozusagen "checkout-only" sein. Ist das möglich?

Answer 1

Meine übliche Lösung besteht darin, eine Reihe von Konfigurationsdateien mit unterschiedlichen Namen zu erstellen und sie unter die Versionskontrolle zu stellen, zusammen mit einem Skript, das die passende Datei an den aktuellen Ort kopiert; die Konfigurationsdatei, die verwendet werden soll, bleibt jedoch unversioniert. Ich könnte zum Beispiel einen Ordner "config_files" haben, der die Dateien "dev.config", "production.config", "qa.config" usw. enthält; meine Deployment-Skripte würden sich darum kümmern, das richtige Skript an den richtigen Ort zu kopieren (sagen wir "App.config").

Sie könnten sogar Hooks verwenden, um dies weiter zu automatisieren.

Answer 2

Sie können eine database.conf.sample die in das Repository gestellt werden soll, und setzen Sie die ignore Eigenschaft für die database.conf Datei.

Answer 3

Die Lösung von tdammers ist eine gute Lösung!

Ich mache es genauso, ich habe eine Reihe von Dateien mit unterschiedlichen Namen wie production.config o adrian_dev.config . Ich checke sie alle ein.

Aber dann habe ich eine Konfiguration (z.B. in Apache config für mod_perl, oder web.xml für Java), in der ich angebe, mit welcher "Umgebung" ich arbeite, was ein String ist, z.B. production so dass das Programm einfach zu z.B. production.config ohne dass Deployment-Skripte Dinge umherkopieren müssen. Wenn Sie eine Änderung vornehmen müssen, können Sie die Konfigurationsdatei einfach einchecken, ohne dass Sie feststellen müssen, dass Sie an einer kopierten Datei arbeiten.

Answer 4

Wenn Sie Maven verwenden, können Sie Profile für die verschiedenen Umgebungen erstellen.

z.B.

local.filter.properties dev.filter.properties beta.filter.properties

In der pom.xml können Sie nun einige Profile definieren und diese auf die verschiedenen Eigenschaftsdateien verweisen.

        <profile>
        <id>dev</id>
        <build>
            <filters>
                <filter>src/main/filters/dev.filter.properties</filter>
            </filters>
        </build>
    </profile>
    <profile>
        <id>java</id>
        <properties>
            <idna.build.deployment.environment>JAVA</idna.build.deployment.environment>
        </properties>
            <build>
                <filters>
                    <filter>src/main/filters/java.filter.properties</filter>
                </filters>
            </build>
    </profile>

Wenn Sie also ein Profil erstellen, wählen Sie das gewünschte Profil aus, und in jedem Profil definieren Sie die Variablen für den DB-Benutzernamen, das Passwort usw.

yourapp.db.username=UserDev
yourapp.db.password=password

und referenzieren Sie in Ihrer database.conf die Eigenschaft mit ihrem Variablennamen

username=${yourapp.db.username}
password=${yourapp.db.password}

Wenn Sie nun Ihre Anwendung erstellen, wählen Sie das Profil aus, das für den jeweiligen Einsatz geeignet ist. Auf diese Weise wird die Conf-Datei zur Kompilierungszeit mit dem richtigen Benutzernamen und Passwort gefüllt, so dass Sie nur eine einzige database.conf-Datei haben.