Hallo Liste.. aktuell stehe ich vor volgendem Problem: ich will / soll via git ein OS-Projekt weiterführen. leider sind die bisherigen "mitwirkenden" leicht verstreut, was deren "Arbeitsmaterial" angeht. zum einen existiert das "offizielle" projekt via git - allerdings etwas eingeschlafen und veraltet, da der Projektleiter das ganze etwas vernachlässigte. zum anderen existiert über einen "sharing-webspace" eine "gemeinschaftsversion" der dort aktiven mitarbeiter. (Dropbox) nun zu meinem problem : ich würde gerne meine "lokale" gitversion als "unabhängigen" Zweig mit der Dropboxversion verbinden. So das ich quasi folgende situation hätte: lokale variante = servervariante mit selektivem abgleich zur dropboxversion (sprich änderungen in der dropbox werden nicht überschrieben, solange ich diese beiden zweige nicht abgleiche via git) jedoch will ich nicht automatisch änderungen an meinem Arbeitszweig direkt - also link zur droppox = nicht gut ich dachte da vielmehr an eine halbeigenständige kopie sprich: ich ändere an file 30 etwas = in der DB ist das file auf "original", dafür file 35 überarbeitet worden. nun geiche ich das ganze ab und "kann" entscheiden ob ich die änderungen an file 35 gleich mitaufnehme oder nicht - wenn ja = bede kopien identisch, ansonsten wird nur mein "neueres" file 30 in die Dropbox "kopiert", file 35 bleibt auf dem geänderten status. irgendwie sind da die tutorials im web nicht sehr hilfreich für diese "verzweigung" - oder ich hab das übersehen ;) Mit freundlichem Gruß, Marco Jäger -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Marco, hallo Leute, Am Montag, 18. Juni 2012 schrieb Marco Jäger:
ich will / soll via git ein OS-Projekt weiterführen.
leider sind die bisherigen "mitwirkenden" leicht verstreut, was deren "Arbeitsmaterial" angeht.
zum einen existiert das "offizielle" projekt via git - allerdings etwas eingeschlafen und veraltet, da der Projektleiter das ganze etwas vernachlässigte.
zum anderen existiert über einen "sharing-webspace" eine "gemeinschaftsversion" der dort aktiven mitarbeiter. (Dropbox)
nun zu meinem problem :
Dein Problem heißt dropbox. Ich garantiere Dir, dass Du mit der geplanten Arbeitsweise nicht glücklich wirst - der Abgleich wird die ein oder andere Packung Aspirin kosten und diverse graue Haare verursachen ;-) Die beste Lösung ist, alles in git zu verwalten - das heißt auch, dass Du die "anderen" Mitarbeiter von git (statt dropbox) überzeugen solltest. Ich erzähl Dir trotzdem noch ein wenig zum Thema "kreative Versionskontrolle" für den Fall, dass doch nicht alle git benutzen wollen ;-)
lokale variante = servervariante mit selektivem abgleich zur dropboxversion (sprich änderungen in der dropbox werden nicht überschrieben, solange ich diese beiden zweige nicht abgleiche via git) jedoch will ich nicht automatisch änderungen an meinem Arbeitszweig direkt - also link zur droppox = nicht gut ich dachte da vielmehr an eine halbeigenständige kopie
Dass Deine lokale Variante ein git checkout (oder nennt man das clone?) ist, sollte klar sein. Für die Dropbox machst Du ebenfalls einen git checkout. Dann kopierst Du den aktuellen Inhalt der Dropbox in diesen Checkout - "git diff" sollte Dir dann die Unterschiede zwischen git und Dropbox anzeigen. Dieser git checkout mit den Dateien aus der Dropbox ersetzt den bisherigen Inhalt der Dropbox. Jetzt kannst Du: - Änderungen aus der Dropbox selektiv zu git commiten - Deine Änderungen in der lokalen Version zu git commiten - alle Deine Änderungen aus der lokalen Version per git pull in die Dropbox übernehmen (ja, alle - das geht nicht selektiv, zumindest nicht so einfach) Vorteil dieser Methode ist, dass git sich ums Mergen Deiner Änderungen und der Dropbox-Änderungen kümmert - Du musst also nur bei Konflikten manuell eingreifen. Der Nachteil ist, dass Du in der Dropbox immer eine gewisse Menge nicht zu git commiteter Änderungen hast - das ist der Teil, der für die grauen Haare zuständig ist ;-) (Aber immerhin gibt es nur diesen Nachteil.) Wie gesagt: es wäre deutlich einfacher, wenn alle Beteiligten git verwenden! Branches sind IMHO nur sinnvoll, wenn Du die Dropbox loswirst - dazu muss ich Dich aber auf die Doku verweisen, weil ich von git nur die Grundlagen kenne ;-) Fürs Archiv: Obiger Vorschlag funktioniert prinzipiell mit jeder Versionsverwaltung, nicht nur mit git. Gruß Christian Boltz --
Mit Evolution hab ich da bedeutend mehr Schwierigkeiten ... Als Outlock-Klon erste Sahne - das Vermurksen von Mail-Headern beherrscht er schon richtig gut. ;-) [> Helmut Zengerling und Thomas Hofer in suse-linux]
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Sat, 23 Jun 2012, Christian Boltz schrieb:
Am Montag, 18. Juni 2012 schrieb Marco Jäger:
ich will / soll via git ein OS-Projekt weiterführen.
leider sind die bisherigen "mitwirkenden" leicht verstreut, was deren "Arbeitsmaterial" angeht.
zum einen existiert das "offizielle" projekt via git - allerdings etwas eingeschlafen und veraltet, da der Projektleiter das ganze etwas vernachlässigte.
zum anderen existiert über einen "sharing-webspace" eine "gemeinschaftsversion" der dort aktiven mitarbeiter. (Dropbox)
nun zu meinem problem :
Dein Problem heißt dropbox.
Ich garantiere Dir, dass Du mit der geplanten Arbeitsweise nicht glücklich wirst - der Abgleich wird die ein oder andere Packung Aspirin kosten und diverse graue Haare verursachen ;-)
Die beste Lösung ist, alles in git zu verwalten - das heißt auch, dass Du die "anderen" Mitarbeiter von git (statt dropbox) überzeugen solltest. [..] Der Nachteil ist, dass Du in der Dropbox immer eine gewisse Menge nicht zu git commiteter Änderungen hast - das ist der Teil, der für die grauen Haare zuständig ist ;-) (Aber immerhin gibt es nur diesen Nachteil.)
Wie gesagt: es wäre deutlich einfacher, wenn alle Beteiligten git verwenden!
Branches sind IMHO nur sinnvoll, wenn Du die Dropbox loswirst - dazu muss ich Dich aber auf die Doku verweisen, weil ich von git nur die Grundlagen kenne ;-)
In der vorletzten c't 13/2012 war dazu ein Artikel: https://www.heise.de/artikel-archiv/ct/2012/13/144_Sozial-programmieren-mit-... Kurzfassung: je nach Anforderung bzgl. "sozial arbeiten" bieten sich IMO github, gitorious oder sourceforge an. Bei github kann man wohl in der Web-UI (WUI) sogar einzelne Code-Zeilen eines commits kommentieren! So könnte man die der Kommandozeilen aversen evtl. leichter von dropbox wegbekommen.
Fürs Archiv: Obiger Vorschlag funktioniert prinzipiell mit jeder Versionsverwaltung, nicht nur mit git.
Nicht alles überall ;) V.a. sind z.B. cvs und subversion auf einen "Master-server" angewiesen (cvs co/commit), bei git hat jeder das komplette repo (git clone) und nur es ist nur eine Frage welches davon 'origin' ist, ansonsten arbeitet jeder an seinem Repo (mit 'git commit' ... (Beim Kernel eben das von Linus, für die diversen Branches die jew. Maintainer der Branches, und bei Bedarf holt sich der Maintainer (z.B. Linus) dann einzelne Patches oder Patchsets per 'git pull' aus den Branches ;) Bei Github und Gitorious geht das lt. c't auch per WUI. HTH, -dnh -- Wir sind nicht Politikverdrossen, sondern Politikerverdrossen! -- Volker Pispers -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (3)
-
Christian Boltz
-
David Haller
-
Marco Jäger