Hat Bitbucket mittlerweile, aber reichtlich versteckt hinter den `<<` im Overview.Dauerbaustelle hat geschrieben:Und es hat so ein Compare-Feature -- die Differenz zwischen einem Branch und einem anderen oder einem Fork und dem Parent anzuzeigen. Das hatte Bitbucket zumindest als ich da war noch nicht.
Einfache Backups und Publikation (wichtig auch wenn man ggf. andere Entwickler einbinden will aber auch sonst nicht unnütz), Rückverfolgung von Änderungen, ermöglich über Branching das Arbeiten an verschiedenen Entwicklungszweigen (angenommen du hast eine tolle Idee für den Kalender und willst sie mal eben ausprobieren, hackst dann daran in einem Zweig um in deiner Ursprungsversion nichts kaputt zu machen) wo du dir danach bequem die Änderungen anzeigen lassen kannst und sie dann eventuell mergen kannst. Dann hast du noch die Möglichkeit mit Tags eine bestimmte Version der Software zu markieren, etwa so wie Bookmarks, so dass du jederzeit zu dieser Version zurückkehren kannst. Wie zu alten Releases.mutetella hat geschrieben:Welchen Vorteil (außer das sehr komfortable Rückgängigmachen von Änderungen) bringt mir eine Versionskontrolle?
Reicht Dir das denn nicht?mutetella hat geschrieben:Allerdings habe ich noch keine wirkliche Antwort auf die Frage: Welchen Vorteil (außer das sehr komfortable Rückgängigmachen von Änderungen) bringt mir eine Versionskontrolle?
Um das noch mal herauszustreichen: Man kann nicht nur jederzeit wieder zu einem alten Stand zurückkehren, sondern man kann sich auch sehr bequem die Änderungen zwischen zwei (nicht notwendigerweise benachbarten) Ständen anzeigen lassen. Das kann manchmal sehr praktisch sein.Leonidas hat geschrieben:Einfache Backups und Publikation (wichtig auch wenn man ggf. andere Entwickler einbinden will aber auch sonst nicht unnütz), Rückverfolgung von Änderungen, ermöglich über Branching das Arbeiten an verschiedenen Entwicklungszweigen (angenommen du hast eine tolle Idee für den Kalender und willst sie mal eben ausprobieren, hackst dann daran in einem Zweig um in deiner Ursprungsversion nichts kaputt zu machen) wo du dir danach bequem die Änderungen anzeigen lassen kannst und sie dann eventuell mergen kannst. Dann hast du noch die Möglichkeit mit Tags eine bestimmte Version der Software zu markieren, etwa so wie Bookmarks, so dass du jederzeit zu dieser Version zurückkehren kannst. Wie zu alten Releases.mutetella hat geschrieben:Welchen Vorteil (außer das sehr komfortable Rückgängigmachen von Änderungen) bringt mir eine Versionskontrolle?
Mercurial erkennt diesen Konflikt und fordert dich auf, zu entscheiden, welche Änderungen du haben willst. Idealerweise hast du vorher ein Diff-Programm (vimdiff oder ähnliches) konfiguriert, das dann gestartet wird und dir beide Dateien nebeneinander anzeigt.mutetella hat geschrieben:Also die Arbeit an verschiedenen Entwicklungszweigen wäre für mich ja echt ein großer Vorteil, an den Punkt komme ich immer wieder, dass ich zum Rumtesten meinen Kalender in ein eigenes Verzeichnis kopiere und die Änderungen, sollten sie sich bewähren, wieder per Hand zurückübertrage... Aber folgendes kann ich mir konkret nicht vorstellen:
Ich stehe gerade vor dem Problem, dass ich in der Klasse, die für die Kalenderansichten zuständig ist, die __init__-Methode "aufräumen" muss, weil da einfach keine klare Struktur mehr drin ist. Wenn ich das in einem separaten Branch mache und parallel dazu an dieser Klasse weiterarbeite und dabei eventuell auch das eine oder andere an der __init__-Methode ändere... Was geschieht dann, wenn ich den "Aufräumzweig" und den "Weitergemachtzweig" zusammenführe? Im "Aufräumzweig" sind mit Sicherheit Änderungen in der __init__-Methode passiert, im "Weitergemachtzweig" potenziell auch.
Das konkrete Problem würde ich eher klassisch angehen: Du änderst die gleiche Methode einfach nicht in verschiedenen Branches.mutetella hat geschrieben:Ich stehe gerade vor dem Problem, dass ich in der Klasse, die für die Kalenderansichten zuständig ist, die __init__-Methode "aufräumen" muss, weil da einfach keine klare Struktur mehr drin ist. Wenn ich das in einem separaten Branch mache und parallel dazu an dieser Klasse weiterarbeite und dabei eventuell auch das eine oder andere an der __init__-Methode ändere... Was geschieht dann, wenn ich den "Aufräumzweig" und den "Weitergemachtzweig" zusammenführe? Im "Aufräumzweig" sind mit Sicherheit Änderungen in der __init__-Methode passiert, im "Weitergemachtzweig" potenziell auch.
Das würde mich auch interessieren. Mit einfachen Feature-Branches hatte ich mit aktuellen Mercurial-Versionen nie Probleme.mutetella hat geschrieben:@cofi:
Weshalb meinst Du, dass Mercurial für die Arbeit mit Branches nicht sonderlich geeignet ist?
Eventuell uebersehe ich etwas, aber `cherry-pick` und `rebase` misse ich schon sehr.lunar hat geschrieben:Das würde mich auch interessieren. Mit einfachen Feature-Branches hatte ich mit aktuellen Mercurial-Versionen nie Probleme.mutetella hat geschrieben:@cofi:
Weshalb meinst Du, dass Mercurial für die Arbeit mit Branches nicht sonderlich geeignet ist?
ad 1) Ich arbeite eigentlich immer mit 'hg clone'. Das andere brauchst du nur, wenn du Zweige im *selben* Verzeichnis verwalten willst. Ansonsten halte ich die Zweige einfach auch räumlich auseinander - ist auf Dauer eindeutiger.mutetella hat geschrieben:Ok, ich hab' mich jetzt für Mercurial entschieden....
Nachdem ich bisher noch überhaupt nicht mit einer Versionskontrolle gearbeitet habe, hätte ich noch ein paar Verständnisfragen:
1. Mit 'hg branch' wird meine Arbeitskopie als Zweig markiert. Mit 'hg clone' erstelle ich einen Klon/eine Kopie des gesamten oder eines speziellen Repository. Ich verstehe den Unterschied nicht wirklich. Ohne jetzt eine haargenaue Anleitung zu benötigen, aber wie gehe ich denn vor, wenn ich vom aktuellen Stand aus einen Zweig eröffnen möchte?
2. Ich habe gerold's Vorschlag übernommen und mir Trac installiert. Um Programmfeatures zu definieren und diese dann Versionen und Komponenten zuzuordnen ist das eine prima Sache. Auch kann ich mir vorstellen, künftig nicht mehr so schnell den Faden zu verlieren, wenn man mal etwas länger nicht mehr bei der Sache war... Für Trac gibt es ja auch eine Mercurial-Unterstützung. Wie kann ich mir das konkret vorstellen, wenn ich z. B. ein Ticket abarbeite: An welcher Stelle kommt hier Mercurial ins Spiel? Wenn ich das Ticket erledigt habe, d. h. neue Programmfeatures fertiggestellt sind, dann mache ich in Mercurial einen commit und in Trac wird das Ticket als erledigt gekennzeichnet. Weshalb muss da eine Verbindung zwischen Trac und Mercurial bestehen?
3. Ähnlich mit der VIM-Unterstützung: Welchen Vorteil hat eine solche Verzahnung zwischen Editor und Mercurial?
Danke schon mal für Eure Unterstützung!!
Gruß
mutetella
Ist damit aber nicht der Vorteil einer Versionskontrolle, Dateien/Verzeichnisse nicht doppelt anlegen zu müssen, vergeudet?Das andere brauchst du nur, wenn du Zweige im *selben* Verzeichnis verwalten willst. Ansonsten halte ich die Zweige einfach auch räumlich auseinander
Nein. Du hast ja nur ein Verzeichnis für jeden Zweig, nicht für jede Version. Um das mal zu illustrieren: Ich habe ein Projekt, das ich an die Bedürfnisse verschiedener Kunden angepaßt habe. Die Grundfunktionalität ist zwar die gleiche, aber es gibt halt kleinere Unterschiede. Die Zahl der Commits, d.h. der sicherungswerten Zwischenstände geht in die Hunderte. Ohne Versionsverwaltung würde ich tatsächlich von jedem dieser Zwischenstände eine komplette Sicherungskopie machen. Bzw. nur noch von einigen ausgewählten. Wodurch aber auch die Möglichkeit verloren geht, sehr kleine Veränderungen zu bewahren. So habe ich für jeden Kunden ein vom Hauptrepo abgeleitetes Repository und durch die Versionsverwaltung auch die Möglichkeit, Änderungen, die alle Zweige betreffen, ohne großen Aufwand von einem Zweig auf die anderen zu verteilen.mutetella hat geschrieben:Ist damit aber nicht der Vorteil einer Versionskontrolle, Dateien/Verzeichnisse nicht doppelt anlegen zu müssen, vergeudet?Das andere brauchst du nur, wenn du Zweige im *selben* Verzeichnis verwalten willst. Ansonsten halte ich die Zweige einfach auch räumlich auseinander