Der beste Weg ist wohl Git.

Grüße

Ab VS 2013 Community Edition ist Git ein vorinstallierter Bestandteil von VS. Setzt man also beim Erstellen das Häcken bei "Add to source control" wird automatisch ein lokales Repository angelegt. Wenn man entsprechend Commits macht, und gezielt branches für tests usw. anlegt, hat man ein praktisches System um Quellcode zu verwalten.

Am besten eine Teilung der Versionsgebung in folgenden Abschnitten : x.z.y bspw:. 1.5.2
Bei jedem Update erhöht sich y

Wie der Vorposter gesagt hat: Git ist einfach die inviduellste Methode

.prox schrieb:

Am besten eine Teilung der Versionsgebung in folgenden Abschnitten : x.z.y bspw:. 1.5.2
Bei jedem Update erhöht sich y

Man beachte aber auch Major-Changes etc. Hierfür wäre Semantic Versioning imho das Beste.
semver.org

Grüße

Der zweitbeste Weg ist dann wohl SolutionExplorer - OpenSource

Nope.
Denn es gibt noch Team Foundation Server (Express) / Visual Studio Online oder auch "einfach" Subversion.

ErfinderDesRades schrieb:

Der zweitbeste Weg ist dann wohl SolutionExplorer - OpenSource

Ich glaube da kommt zuvor noch eine lange Liste, bestehend aus dem Großteil der übrigen Versionsverwaltungssystemen.
TFS, SVN, Mercurial, ...

ma abwarten, für was der TE sich entscheidet.

Am Ende findet er noch Gefallen daran, wenn seine zwischenzeitlichen Solution-Sources einfach als durchnumerierte Zips in einem UnterOrdner abgelgt wern.

ErfinderDesRades schrieb:

Am Ende findet er noch Gefallen daran, wenn seine zwischenzeitlichen Solution-Sources einfach als durchnumerierte Zips in einem UnterOrdner abgelgt wern.

Das mag vielleicht sogar der Fall sein. Wenn dies seine Anforderung ist. Dann reicht im jedoch ein einfach zip Tool und wenn er es komfortabel möchte eine batch Datei dazu.
Ein Versionsverwaltungssystem ist das Teil jedoch definitiv nicht. Die einzige Gemeinsamkeit die ich hier erkennen kann ist, dass irgendwo auf der Platte ein Backup mit Sourcen liegt. Mehr kann das Teil nicht. Sowas auch nur Ansatzweise mit Git, TFS oder auch älteren Systemen wie SVN,... zu vergleichen ist nicht nur falsch sondern schlicht weg nicht möglich. Es macht was komplett anderes als solche Systeme. Am ehesten kommt dein Tool meiner Meinung nach an ein Fullbackup hin. Wenn ich mir jedoch teilweise Projekte von mir anschau, dann wirds da mit dem Speicher recht schnell eng. Wenigstens ein incremental backup wäre hierbei wünschenswert. Aber auch da, spätestens wenn gängige Anforderungen wie z.b. in einem Team arbeiten, das synchronisieren, mergen, eine alte Version bearbeiten und damit alle neuen anpassen etc. dazu bekommt, bist du da hoffnungslos verloren.
Zip-Tool welches in VS integriert ist: ja. Versionsverwaltung (für mich) ganz klar: nein.

thefiloe schrieb:

Sowas auch nur Ansatzweise mit Git, TFS oder auch älteren Systemen wie SVN,... zu vergleichen ist nicht nur falsch sondern schlicht weg nicht möglich. Es macht was komplett anderes als solche Systeme.

Stimmt.
Es ist nicht mit einem Versionierungssystem zu vergleichen - das war auch nie meine Absicht.

Mit SolutionExplorer hier anzukommen ist einfach (m)eine Antwort auf die Frage des TEs:

Da-Flo schrieb:

wenn mal etwas schief geht immer wieder zurück und dort weitermachen oder mir anschauen wie der Stand damals war [...] was sind eure Vorgehensweise ?

Meine Vorgehensweise ist:
Gelegentlich, wenns grad lauffähig ist, und immer vor größeren Umbauten, klicks ich einmal drauf, und was ich bis dahin geschafft habe ist sowohl gesichert, als auch steht als lauffähiger Vergleichs-Solution zur Verfügung, falls ich eine Verschlimmbesserung verzapft habe.

@ErfinderDesRades

Keine Ahnung was deine bisherigen Erfahrungen mit Versionsverwaltung sind, ich hatte in mehreren Beiträgen jedoch den Eindruck, dass du einer professionellen Versionsverwaltung eher ablehnend gegenüber stehst (korrigier mich ggf) - das erscheint mir umso verwunderlicher, als dass du ansonsten ja immer großen Wert darauf legst, die Werkzeugkiste der Entwicklungsumgebung auch effizient zu nutzen.

Ich bin vor einer Weile von SVN auf GIT umgestiegen und ich bin schwer beeindruckt vom Workflow der mit GIT einhergeht. Insbesondere deine oben beschriebene Vorgehensweise passt zu GIT wie die Faust aufs Auge, zumal in den neueren Versionen von Visual Studio eine wirklich bequeme Integration von GIT existiert - ich kann mir Programmieren ohne GIT nicht mehr vorstellen (das gilt nicht für jedes Versionsverwaltungssystem!).

Anbei ein nett gemachtes Video zum Workflow mit GIT in VS2015 (streckenweise bisschen langatmig, dafür werden die wichtigsten Szenarien für Einsteiger mit praktischen Beispielen abgedeckt)


ein paar interessante Zeitmarken:
~6min - erste einfache Commits
~12min - history graph & sync to server
~19min - User/Commiter details
~21min - gitignore
~25min - branching
~35min - tags
~37min - merges

Das Ganze wird locker präsentiert und man kann es gut nebenbei laufen lassen. Vielleicht schaust du mal rein

Nö - ich hab ühaupt nix gegen VersionsVerwaltungssysteme. Nur da ich kein Team bin, kommt mein "Zipping-Tool", wie theFiloe es treffend bezeichnet , meinen Bedürfnissen besser entgegen.
Aber ich glaub, selbst wenn ich Team-Mitglied wäre und wir eine Versionsverwaltung nutzen würden, würde ich trotzdem auch weiterhin immer wieder mal auf "BackZip" klicksen, und mein aktureller Code-Snapshot wär auf Platte. Ein Zipping-Tool bedient halt einen etwas anderen Bedarf.

Auch stieß ich bei meinen Git-Versuchen auf folgendes prinzipielles Problem:
Ich hab ja recht vielseitige Helpers-Projekte, die ich in jedes Projekt einbinde, was ich anfange. Und in jedem Projekt kanns beim dran arbeiten vorkommen, dassich auch an den Helpers noch kleine Verbesserungen vornehme.
Bei meinen Git-Versuchen, das zu konfigurieren trat nun das Problem auf, dass ich deshalb alle meine Projekte insgesamt in ein gemeinsames Repository zu stellen hätte . Anders wäre nicht zu gewährleisten, dass beim Rückschritt in einem Projekt, auch die Helpers rückschreiten.
Aber son Monster-Repository scheint mir ganz unhandhabbar, und ausserdem hätte dann ja jedes Rückschreiten in einem einzelnen Projekt immer gleich mein ganzes System eine Zeitreise machen lassen - kann ich auch nicht brauchen.

Mein Zipping-Tool hingegen (man muss übrigens garnix konfigurieren, weil das liest aus dem Solution-File, was eingebunden ist) - ein Klick, und Backup done. Und wenn ich das dann entpacke habe ich einen lauffähigen Projekt-Klon, bei dem auch die Helpers geklont sind, sodass ich zweimal das gleiche (aber nicht dasselbe!) offen habe und vergleichende Tests machen kann etc.. - das war auch son Punkt, der mir bei Git wesentlich umständlicher erschien, wenn nicht gar unmöglich.
(Naja - muss ja iwie möglich sein, letztendlich kann man bei GitHub denn ja auch die Komplett-zipps downloaden.)

naja egal.
jdfs. ich hab embedded utube in meim Browser deaktiviert - hast du vlt. einen normalen utube-Link?

Ach - und in deim "Inhaltsverzeichnis" - fehlt mir auch genau der Punkt:
- wie restaurieren / sandbox-Restaurieren, wenn man Verschlimmbesserungs-Fehlern nachspüren muss?
Also der Use-Case, dass im aktuellen Stand ein Fehlverhalten auftritt, was die Vorgänger (oder Vor-Vorgänger) nicht hatten. Da will man ja den akt. Stand eiglich behalten, und durch Vergleiche mit früherem rauskriegen, wo man den Bug verbockt hat.
Ist meine Haupt-Nutzung meines Snipping-Tools, und übrigens genau auf diesen Use-Case scheint mir Da-Flos Frage auch abzuzielen (post#1).

@ErfinderDesRades git hat submodules

Vergleiche zu alten versionen gehen auch ganz einfach, dafür sind die difftools da, welches VS auch eins integriert hat außerdem hast du bei git genauso die unterschiedlichen Stände, die du dir ebenso einzeln rauspicken könntest, wie bei deinen Zip-Tools. Was git halt braucht ist eine gewisse einarbeitungszeit und mMn auch eine Konsole.

@ErfinderDesRades

Hier ist der Link: youtu.be/egy2r6ReaeI

Zum Aufspüren von Unterschieden hast du, wie jvbsl bereits schrieb, die Diff-Tools. Zwischen verschiedenen Versionsständen springst du mittels History (12min) und Branches (25min) hin und her. Das ist schon ziemlich komfortabel gelöst und kein Vergleich zum Krampf den z.B. SVN bedeutet. Gerade das sehr einfache Branching hat mich von GIT überzeugt. Mittlerweile mache ich von jedem Kleinscheiss zunächst einen Branch bevor ich loslege. Das schafft eine gewisse Sicherheit (altes geht nicht kaputt) und man ist eher bereit etwas zu "riskieren".

Bis auf die initiale Konfiguration der Repositories, kann ICH auf die Konsole ganz gut verzichten. Die Integration im Studio reicht MIR vollkommen.

@jvbsl was ist ein git-submodule - kriegt man damit einen Klon-Auszug eines Projekts, inklusive Helpers, auf einem früheren Stand?
Mit eim Diff-Tool habich schon gearbeitet - bringt für vergleichende Tests in meim Sinne nichts. Ich will ja mal die aktuelle Version durchsteppen, mal den Vorgänger

Mit Submodules habe ich mich noch nicht beschäftigt. Wenn ich einen Clone eines alten Versionsstandes brauche, springe ich per History dort hin und lege mir bei Bedarf einen Branch davon an.

Generell kannst du zwischen verschiedenen Versionsständen und/oder Branches mit einem Klick umschalten. Ich mache es manchmal auch so, dass ich das Studio zweimal mit verschiedenen Versionsständen öffne - evtl geht das aber auch geschickter, ich beschäftige mich mit GIT noch nicht so lange.

ErfinderDesRades schrieb:

Mit eim Diff-Tool habich schon gearbeitet - bringt für vergleichende Tests in meim Sinne nichts. Ich will ja mal die aktuelle Version durchsteppen, mal den Vorgänger

Was macht es für einen Unterschied ob ich das Projekt aus einem übersichtlichen und gut organisierten (und dazu noch komprimierten) git repo rausziehe oder die entsprechende Version aus einem Ordner raussuche und entzippe?
Bis auf ein paar Nachteile bei letzterem sehe ich vom Resultat keine Unterschiede.

aber mit einem Diff-Tool zieht man doch kein Projekt raus, oder?

Jdfs. was ich als Diff-Tool hatte, damit hat man Text-Dateien verglichen, also man hatte 2 Editoren nebeneinander, und unterschiedliche Textstellen waren hervorgehoben.