Subversion und VisualSVN für Ein-Mann-Entwicklung

[jfheins]

Du kannst bei den grafischen Clients auch mehrere verschiedene GUIs auf dem selben Computer benutzen. Du bekommst dann schon eine Fehlermeldung, wenn die sich ins Gehege kommen.
Bei SVN heißt die irgendwie "svn working copy locked". Bei git bekommst du

Zitat:

fatal: Unable to create 'v:/path/to/files/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

Auf einem anderen Rechner kannst/musst du dann eh andere Clients einsetzen. SourceTree gibt es bspw. nicht für Linux. TortoiseGit gibt's nicht für macOS.

[Assarbad]

Zitat von Harry Stahl:

1. Kann man für die verwendeten Clients (wenn Grafischer Client) eigentlich unterschiedliche unter Windows / MAC / Linux nutzen, oder ist es erforderlich (sinnvoll) einen vom gleichen Hersteller zu nutzen?

Kannst von der Sache her beliebige Clients benutzen. Wenn die Versionen zu weit auseinander sind - aber das muß schon sehr weit auseinander sein - kann es u.U. zu Problemen kommen. Ist aber äußerst unwahrscheinlich, da die Übertragung normalerweise in einer Form stattfindet welche sogar die jeweils ältesten Clients verstehen. Die dort lokal initialisierten Repos haben dann nur möglicherweise nicht alle Features aktiviert. Aber wie gesagt, da müßtest du dir schon aktiv Mühe geben um einen solchen Versionsunterschied künstlich zu erzeugen. Diese Aussage gilt sowohl für Mercurial wie auch für Git.

Zitat von Harry Stahl:

2. Was vergleichbares wie den VisualSVN-Server (herrlich leicht zu installieren und zu verstehen) gibt es nicht für GIT und Windows?

Git ist jene Versionskontrolle zu der es ernsthaft mehrere verschiedene Wrapper gibt um die Benutzung zu vereinfachen. Mercurial hat und braucht sowas nicht, weil es von Haus aus benutzerfreundlich daherkommt. Wenn du also "herrlich leicht zu installieren und zu verstehen" als Maßstab nimmst, könnte Git unter Umständen die falsche Wahl sein.

Mir ist nichts dergleichen bekannt wie VisualSVN-Server jedoch für Git, aber ich hoste sowas nicht auf Windows. Sicher kann jemand anderes weiterhelfen.

[warschonweg]

Woher kommt eigentlich die irrige Annahme, ausgerechnet unter Windows sei irgendwas komplizierter zu installieren als unter Linux?

[Assarbad]

Zitat von warschonweg:

Woher kommt eigentlich die irrige Annahme, ausgerechnet unter Windows sei irgendwas komplizierter zu installieren als unter Linux?

Keine Ahnung, wer hat denn das so behauptet? Ein Zitat könnte helfen.

Übrigens war dies mit Git einst der Fall; also daß es komplizierter zu installieren war. Git for Windows gibt es noch nicht so lange. Das alternative Vorgängerprojekt mußtest du selbst lokal kompilieren und zwar ohne dafür eine code-signierte Basis (sprich Compiler) nehmen zu können. Das Resultat war mit etwas Glück Git als Kommandozeilenversion und mehrere Gigabyte Objektdateien. Juhu! Das war aber auch bevor libgit2 eingeführt wurde, wenn ich mich recht entsinne. Seit es das gibt, sprießen die Clients ja wie die Pilze aus dem Boden (inklusive Visual Studio etc). Und Git for Windows sehe ich allein aufgrund der Signaturen als Riesenfortschritt an.

Ansonsten ist Windows vor allem anders und in Sachen Netzwerkstack gegenüber BSD oder Linux durchaus benachteiligt. Aber man kann sich das auch schönreden. Hab ich schließlich auch gemacht, als ich noch aktiv Windows-Domänenadministrator war ... einfach Apache draufgeklatscht damals und so getan als ob damit alles in Butter wäre. Lief auch, nur eben nicht so schnell wie auf Linux oder eben FreeBSD.

Aber auch auf der Unixseite habe ich schon einige hartgesottene Adminurgesteine kennenlernen dürfen, die sich an einen schnellen und effizienten Webserver ala Nginx oder Lighttpd nicht gewöhnen können und deshalb bei Apache blieben, oder nicht wußten auf welchem OSI-Layer OpenVPN operiert und deshalb meinten man könne damit keinen Tunnel buddeln, bis ich ihnen das Gegenteil bewies (es ging um die Verbindung zwischen zwei Firmensitzen).

[bra]

Zitat von warschonweg:

Woher kommt eigentlich die irrige Annahme, ausgerechnet unter Windows sei irgendwas komplizierter zu installieren als unter Linux?

Das ist bei Programmen, die ursprünglich von Linux kommen, gar nicht so ungewöhnlich - da müssen teilweise erst dutzende sonstige Programme (Perl, Apache usw.) installiert und konfiguriert werden.

[Sherlock]

Fairerweise muss man sagen, daß da alles unter Unixen nur darum so einfach ist, weil es in der Regel schon installiert ist, und sich viele kluge Köpfe Gedanken zu Standardinstallationen gemacht haben. Wenn man aus diesen wirklich guten Standards ausbrechen möchte kann es schon mal haarig werden.

Dennoch habe ich nur Unix-Server, weil sie einfach so leicht zu administrieren sind. Wer KlickiBunti für einfach hält, hat noch nicht wirklich administriert. Auch unter echten Windows Servern ist die Konsole optimal. Nicht umsonst hat MS sehr viel Zeit und Energie in die Powershell gesteckt.

Sherlock

[Aviator]

Zitat von Sherlock:

Nicht umsonst hat MS sehr viel Zeit und Energie in die Powershell gesteckt.

Haha. Das ist wohl wahr.

Ist zwar etwas OT, aber ich habe anfang des Jahres (und auch jetzt immer mal wieder) einen neuen Exchange 2016 eingerichtet. Es geht zwar sehr vieles über das Exchange Admin Center, aber einige "tiefer" greifende Systemeinstellungen kann man nur über die Exchange Management Shell (welche auf der PowerShell basiert) einrichten.


Aber um noch etwas zum Thema beizutragen:

Ich benutze auch seit etwa 1 - 1,5 Jahren eine Versionsverwaltung. Anfänglich SVN, jetzt GIT. GIT hat wohl einige Vorteile, hat mir aber auch schonmal ganz übel mein Projekt zerschossen. Wahrscheinlich eher aus Unwissenheit meinerseits, aber das hat mich wirklich geärgert. Hatte dann schon einige Stunden Zeit gekostet, bis ich meinen aktuellen Stand wieder hatte.

Mein Problem bei einer Versionsverwaltung ist immer, dass ich vergesse etwas einzuchecken wenn ich etwas gelöst habe. Auch mit dem Branching habe ich so ein Problem. Wann lege ich einen an und wann nicht? Oder lösche ich bestehende Branches nochmal oder lasse ich die für alle Zeiten stehen?

PS: Auch ich arbeite nicht im Team, sondern alleine. Trotzdem würde ich jetzt sagen, dass es sich schon lohnt. Benutze allerdings nicht die GIT Shell, sondern SourceTree.

[jaenicke]

Zitat von Aviator:

Auch mit dem Branching habe ich so ein Problem. Wann lege ich einen an und wann nicht?

Das lohnt sich nur, wenn du eine längere Entwicklung, z.B. ein neues Feature, machst und daneben noch etwas anderes an dem Projekt machst. Zum Beispiel auch einen Bug analysieren.
Wenn du das neue Feature dann in einem eigenen Branch hast, kannst du mit dem unveränderten Projekt debuggen usw. und mergst das neue Feature dann erst am Ende in den Master-Branch.

[Aviator]

Zitat von jaenicke:

Zitat von Aviator:

Auch mit dem Branching habe ich so ein Problem. Wann lege ich einen an und wann nicht?

Das lohnt sich nur, wenn du eine längere Entwicklung, z.B. ein neues Feature, machst und daneben noch etwas anderes an dem Projekt machst. Zum Beispiel auch einen Bug analysieren.
Wenn du das neue Feature dann in einem eigenen Branch hast, kannst du mit dem unveränderten Projekt debuggen usw. und mergst das neue Feature dann erst am Ende in den Master-Branch.

Alles klar. So hatte ich es bisher auch zum Großteil gemacht. Löschst du denn die Branches danach immer wieder nachdem du gemergt hast? Wäre ja irgendwie sinnlos den zu behalten, weil der letzte Commit ja dann u.U. sowieso nicht mehr gültig wäre, oder?

[Fritzew]

Wir benutzen in etwa das Schema im Anhang.
Bis vor 2 Jahren waren wir auf SVN.
Git hatte eine Lernkurve aber ich muss sagen, ohne möchte ich nicht mehr arbeiten.
Wenn man erst mal mit der Philosophie vertraut ist geht es ganz gut.