Privaten SVN Server einrichten!

[Mavarik]

Oh man!

Mercurial läßt sich nicht installieren.
GitStack will als erstes mal das ich den IIS für die Installation stoppe. Cool Produktiver Server erstmal down.
Naja unnötig zu sagen das GitStack nicht läuft, keine GUI auf dem Server hat und die "Config" Webseite nicht angezeigt werden kann.

Das fängt ja richtig gut an.

Mavarik

PS: Der SVN-Server war in einer Minute installiert...

[Meflin]

Du brauchst für Git keinen "Server". Lediglich SSH-Zugang für deine Nutzer (also dich selbst). Alles, was dann noch nötig ist, ist ein "git init" in dem Verzeichnis wo das Repo sein soll. Danach kannst du fröhlich clonen (und pushen / pullen).

[Mavarik]

Zitat von Meflin:

Du brauchst für Git keinen "Server". Lediglich SSH-Zugang für deine Nutzer (also dich selbst). Alles, was dann noch nötig ist, ist ein "git init" in dem Verzeichnis wo das Repo sein soll. Danach kannst du fröhlich clonen (und pushen / pullen).

Und wie wird der Zugriff auf den zentralen Server geregelt und welcher User auf welche Repo's zugreifen darf?

Mavarik

[Meflin]

Zitat von Mavarik:

Und wie wird der Zugriff auf den zentralen Server geregelt und welcher User auf welche Repo's zugreifen darf?

Ganz einfach, jeder der vom Betriebssystem Zugriff auf das Repo-Verzeichnis bekommt hat den auch über git (bzw. eben nicht). Bisher klangen deine Beschreibungen aber nicht danach, dass du großartige Nutzerverwaltung benötigen würdest. Wenn das doch der Fall ist, wäre natürlich etwas wie GitStack angebracht. Die machen dann aber "unter der Haube" auch nichts anderes, als Zugriffsrechte auf Verzeichnisse zu setzen. Es gibt halt einfach keinen "zentralen Server" bei Git. Das was du haben willst, ist aus Git-interner Sicht nichts anderes, als ein weiterer clone des Repositories.

[Mavarik]

Ist es richtig, dass die Repositories immer im Unterverzeichnis .\git im selben Verzeichniss wie der Source liegt?
Das vergrößert ja die Datensicherung um ein vielfaches.

Und die Ignores scheinen auch nicht zu funktionieren...

SVN mag zwar alt sein, aber stellt sich mir viel ausgereifter dar.

[jfheins]

Zitat von Mavarik:

Ist es richtig, dass die Repositories immer im Unterverzeichnis .\git im selben Verzeichniss wie der Source liegt?
Das vergrößert ja die Datensicherung um ein vielfaches.

das kommt schon darauf an, was du darin speicherst und wie. Große BLOBS (insb. welche, die sich oft verändern) solltest du woanders ablegen und nicht im git. exe-dateien gehören schonmal nicht hinein.
Außewrdem verwendet git ja Komprimierungsalgorithmen, die die Größe deines .git Ordners relativ klein halten. Ich entwickle jetzt noch nicht so umfangreiche Software, aber so als Beispiel:
FEM--Repo: Viele Binärdateien vom FEM Programm, .git: 7MB, Arbeitsverzeichnnis: 10,8MB

MATLAB-Code: .git 570KB, Arbeitsverzeichnis: 268KB (Enthält noch Branches)

Und zur Sicherung reicht es ja eigentlich auch, den .git Ordner zu sichern. Da ist ja alles drin.

Zitat:

Und die Ignores scheinen auch nicht zu funktionieren...

Bei mir klappt das einwandfrei. Eine Datei ".gitignore" neben dem .git Ordner mit dem Inhalt

Code:

*.aux
Auxiliary/
*.pdf
!Bilder/*.pdf

Irgnoriert z.B. alle *.aux Dateien, alle Dateien in dem Unterordner "Auxiliary" und alle pdfs außer die pds im Unterordner "Bilder"

[Meflin]

Zitat von Mavarik:

Ist es richtig, dass die Repositories immer im Unterverzeichnis .\git im selben Verzeichniss wie der Source liegt?
Das vergrößert ja die Datensicherung um ein vielfaches.

Git speichert seine Metadaten (also die komplette History) immer in einem .git Ordner im Repository, das ist richtig. Den gibt es aber nur ein mal pro Repository, nicht für jedes Verzeichnis, in dem du in deinem Repository Source Files hast. Inwieweit das Datensicherung jetzt erschweren soll, erschließt sich mir nicht.

Zitat:

Und die Ignores scheinen auch nicht zu funktionieren...

Selbstredend funktionieren die ignores. Vielleicht "trackst" du die Datei schon, die du jetzt ausschließen willst? Das hat nämlich Vorrang vor den ignores, die sich "lediglich" auf den "git add"-Teil des Workflows auswirken.

[Elvis]

Du würdest wohl eher den Server sichern, anstatt deinen lokalen Ordner.

Git bringt dir die Möglichkeit einen Ordner samt Unterordnern zu versionieren.
Das braucht keinen Server und keinen anderen Ordner irgendwo anders (wie bei SVN) und du hast auch nicht in jedem unterordner einen ".svn"-Ordner.

Git gibt dir außerdem die Möglichkeit diesen versionierten Ordner mit einem anderen abzugleichen (einem Server, einem anderen Ordner auf deiner HDD, oder der Rechner deines Kollegen)

Was du für den zetralen Teil willst, ist eine Software, die Git dort für dich verwaltet.
Ein genanntes Beispiel war zum Beispiel GitLab (wenn du es bei dir installieren willst).

Andere (die auch das Hosting für dich übernehmen) wären Kiln, Github, oder Bitbucket.
Diese Tools geben dir ein Web frontend, mit dem du sehen kannst, was so alles passiert. Oder auch Berechtigungen vergeben kannst.
Und sie geben dir die Möglichkeit Tasks mit dem Code zu verknüpfen. (Wenn du das willst)

Wenn du dich allerdings weiterhin von Vorurteilen leiten lässt[1], wirst du niemals ein neues Werkzeug für irgendetwas als sinnvoll erachten. Denn man muss erst etwas damit arbeiten, bevor man es gut genug kennt um zu wissen wie gut es wirklich ist. Und etwas, was merklich besser als das alte ist, wird fast immer komplett anders zu bedienen sein (sonst wäre es wohl kaum besser)
So eine Einstellung hilft nicht sonderlich wenn Antworten haben will, btw.

[1] und genau das war dein letzter Beitrag!

[Lemmy]

Zitat von Mavarik:

SVN mag zwar alt sein, aber stellt sich mir viel ausgereifter dar.

beide Werkzeuge sind ausgereift. Das Problem ist, dass git einfach anders funktioniert und dadurch der Workflow ein anderer ist. Leider ist die Lernkurve bei git auch steiler. Mit SVN bin ich auch schnell zurecht gekommen, bei git habe ich heute noch manche Schwierigkeit.

Bevor du anfängst irgend welche git "Server" aufzusetzen, installier dir das mal lokal auf einem "nackten" Rechner und teste das aus. Lies dir dazu entsprechende Tutorials durch, anders wirst Du nur schwer einen Zugang finden.

[Mavarik]

Das Problem war wohl eher SourceTree anstatt git.

TortoiseHg läuft da auf anhieb und funktioniert auch wie erwartet.

Wenn ich jetzt noch den zentralen Server für meine Tests hinbekomme, werde ich Euer Empfehlung folgen.
(Obwohl ich bei meinen Merge-Test die gleichen Konflikte bekomme wie bei SVN. Vielleicht ändert sich das wenn ich mal "richtigen" Sourceocde nehme und nicht "Kochrezepte")


@Elvis
Ich Danke für Deine Ratschläge und Deine Postings, aber fühle Dich bitte nicht angegriffen. Ich berichtet lediglich von
meinen Erfahrungen und Problemen auf die ich stoße.

Mavarik