Subversion und VisualSVN für Ein-Mann-Entwicklung

[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.

[jaenicke]

Im Team macht da finde ich ein solcher Ablauf Sinn:
http://nvie.com/posts/a-successful-git-branching-model/

Bei einem einzelnen Entwickler wird man das eher nicht so konsequent machen.