Konflikte mit zwei verschiedenen Repositories

Endwiggler schrieb:
> klar, ein einziger SVN Server

So klar ist das nicht. Linus Torvalds schafft es, den Linux-Kernel 
verteilt entwickeln zu lassen. Da werdet ihr paar Hanseln doch auch 
zusammenkommen. Kannst dir ja von Herrn Torvalds was abschauen.

Endwiggler schrieb:
> Nun ist es so, dass wir auch ab und zu Spezial-Anpassungen machen und
> diese einchecken. Wir haben aber unser eigenes Repository (auch SVN).

Und achtet Ihr auch darauf, dass die Verzeichnis- und Dateistruktur 
genauso aufgebaut ist wie bei dem externen Dienstleister?

> Idiotischerweise verwendet jeder sein eigenes Repository!

Alles Iditioten, außer Dir natürlich.

> Klarerweise
> haben wir schon oft den Vorschlag gemacht auf ein Repository zu setzen,
> dies scheiterte anscheinend an rechtlichen und organisatorischen
> Gründen,

Genau solche Gründen darf man eben nicht vernachlässigen. Von dem großen 
Ziel, auf einer gemeinsamen Quellcodebasis zu arbeiten, muss man sich 
leider sehr häufig verabschieden, auch wenn es manchmal als die 
einfachste Lösung erscheint. Es kann sehr gute Gründe geben, warum man 
z.B. bestimmte Checkins oder Verzeichnisse Dritten nicht zur Verfügung 
stellen möchte.

> (oder einfach weil die Firma bekloppt ist).

"Die Firma" ist der nur der Name, unter der ein eingetragener Kaufmann 
tätig ist. Du meinst wahrscheinlich das dahinter befindliche 
Unternehmen. Dieses wird aber dummerweise durch seine Mitarbeiter 
verkörpert, also auch durch Dich.

> Bis jetzt wurden die Libs und Sourcen über SFTP ausgetauscht (!). Wenn
> wir was neues haben laden wir es hoch und vice versa.

Das ist doch durchaus praktikabel. Wichtig ist jedoch, wie die Daten 
jeweils organisiert sind. Und befinden sich geeignete(!) 
Lieferinformationen dabei, z.B. README, Änderungslisten, usw.?

> Klar, dass da ab und zu etwas vergessen geht, es Merge Konflikte gibt,
> oder man sich plötzlich wundert, wo (oder von wem) die Änderung kommt.

Das heißt also, dass Ihr Entwickler (also z.B Du) den Austausch solcher 
Lieferungen nicht hinreichend erst nehmt. Es ist gar nicht so klar, dass 
dabei etwas vergessen wird, wenn man geeignete Lieferprozesse realisiert 
hat. Unvollständige Lieferungen kommen vor allem dann zustande, wenn man 
mal schnell irgendetwas aus einer Entwickler-Sandbox zusammenkopiert. 
Deswegen ist es immens wichtig, für Lieferungen immer saubere, frische 
Checkouts in leere Verzeichnisstrukturen zu verwenden und darauf den 
Buildprozess durchzuführen. Dann merkt man sofort, ob alles vollständig 
ist. (*) Dieser Vorgang ist durchaus auch ohne Lieferung an Dritte 
ratsam, sondern stellt die Konsistenz auch für interne Zwecke sicher. 
Wenn man mit Buildservern wie z.B. Jenkins arbeitet, denen man nur ein 
Label oder Tag des Versionskontrollsystems verabreicht, hat man das 
perfektioniert.

> An Fehlern sind aber trotzdem wir schuld, wenn wieder mal etwas nicht
> funktioniert. Nun haben wir ein Meeting, wo wir Chefs erklären müssen,
> wo das Problem liegt und wie wir das verhindern können.

Und ganz genau so ist es auch richtig.

> Blöderweise sind die nicht sehr IT-affin und haben selbst noch keine
> Ahnung oder sich noch nie mit SVN oder Git o.ä. beschäftigt.

Aha, und wieder sind die anderen alle blöd. Ihr versucht also, Eure 
eigene mangelnde Disziplin bei der Lieferung und Integration Dritten in 
die Schuhe zu schieben?

> -Gibt es ein Konzept wie diesen Mist umgehen kann (klar, ein einziger
> SVN Server) - wenn aber kurzfristig nicht möglich?

Dann muss man sich eben geeignete Lieferprozesse überlegen. Lieferungen 
müssen immer VOLLSTÄNDIG sein und dürfen NIEMALS nur aus einzelnen 
hingeworfenen Dateihäppchen bestehen, auch wenn es zunächst 
verschwenderisch erscheint, wegen ein paar geänderter Bytes einen viele 
Megabyte großen Dateihaufen zu liefern.

Lieferungen müssen KONSISTENT sein, siehe oben. Und sie müssen 
geeignet gekennzeichnet sein. OurGreatSoftware-1.0-new-version.zip ist 
kein geeigneter Name.

Und auch die Integration fremder Software muss entsprechend ablaufen. 
Sinnvollerweise versioniert man dabei alle Integrationsschritte:

ZIP-Datei --> OurGreatSoftware/transfer/lieferant/in/version
entpackte Quellen --> OurGreatSoftware/branches/lieferant/version

Von dort ausgehend führt man die Software auf einem separaten 
Merge-Branch zusammen, bis sie letztendlich in den oder die 
Arbeitsbranches bzw. den Trunk (je nach Arbeitsmodell) integriert wird.

> -wie kann man Chefs die nicht wirklich viel Ahnung von Entwicklung
> haben, das Problem erklären?

Ganz einfach: "Hallo Chefs, wir Entwickler sind zu faul, uns über 
geeignete Austauschprozesse hinreichend viele Gedanken zu machen und 
einen reproduzierbaren Arbeitsablauf einzuführen. Stattdessen 
verschwenden wir lieber ein Vielfaches der Zeit damit, 
herumzulamentieren und auf sehr fehlerträchtige Art und Weise die 
Softwarestände irgendwie zusammenzuflicken."


Zu (*):

Ich kenne leider auch einige drittklassige Entwickler, die monatelang 
oder jahrelang immer auf demselben Arbeitsverzeichnis arbeiten und nicht 
sicherstellen, dass dort keine Dateileichen usw. herumliegen. Dabei kann 
ich mich noch an den Fall erinnern, in dem ein ehemaliger Kollege die 
Lieferung eines sehr wichtigen Firmwarestandes an einen großen Kunden 
durchführen sollte. Ich fand es ohnehin ziemlich fahrlässig, diesen 
Idioten damit zu beauftragen. Ich drängte ihn, für die Lieferung 
unbedingt eine frische Sandbox auszuchecken, dort alles zu kompilieren, 
kurz zu testen usw.. Bei solchen wichtigen Lieferungen ist es sogar 
wichtig, anschließend die Sandbox inklusive aller Artefakte des 
Buildprozesses z.B. in einer ZIP-Datei o.ä. zu packen, um im Falle von 
Problemen ggf. sogar noch Forensik betreiben zu können.

Und was machte der Typ: er machte ein Update auf seiner Sandbox, checkte 
einige eigene Dateien ein, kompilierte, lieferte die Firmware an den 
Kunden und löschte seine Sandbox, um am nächsten Tag auf einem sauberen 
Stand aufzusetzen zu können, und ging nach Hause.

Am nächsten Tag dann die Überaschung: wir anderen Entwickler führten 
ebenfalls ein Update durch und stellten beim Kompilieren fest, dass 
mehrere Dateien fehlten. Der o.a. Entwickler hatte vergessen, ein paar 
von ihm selbst erstellte Quellcodes einzuchecken. Dies war bis dahin 
niemandem aufgefallen, da er an einem recht isolierten Modul arbeitete 
und die Verknüpfung mit seinen neuen Quellcodes erst durch die o.a. 
Checkins für jedermann sichtbar wurden. Der Trottel hatte aber seine 
Sandbox gelöscht, so dass seine Quellcodes unwiderbringlich verloren 
waren. Und natürlich hat er auch nicht - wie es eigentlich 
vorgeschrieben war - auf einem Netzwerklaufwerk gearbeitet, das der 
regelmäßigen Datensicherung unterworfen war, sondern nur auf seinem 
eigenen PC.

Da das gelieferte Firmwareupdate ein paar sehr wichtige Bugfixes 
enthielt, führte der Kunde auch gleich ein großes Rollout durch. Dies 
bedeutete, dass sich plötzlich zigtausende an Geräten mit einem 
Firmwarestand befanden, der nicht mehr reproduzierbar war! Zum Glück gab 
es kein Problem mit der Firmware, und es gab genug Zeit, die fehlende 
Software noch einmal nachzuimplementieren.

Dr. Sommer schrieb:
> Git wäre hier genau die Lösung...

Nein, nicht zwingend. Das funktioniert nur dann reibungslos, wenn alle 
Beteiligten hinreichend kompatible Verzeichnisstrukturen verwenden.

> Das geht dezentral, ihr könntet eure
> Änderungen halbautomatisch an die andere Firma schicken bzw. die Firma
> macht ein "pull" auf euer Repo.

Damit werden aber auch die Checkins sichtbar, die eigentlich für die 
andere Partei verborgen bleiben sollen.

> Oder ihr verwendet beide GitHub oder
> BitBucket (mit nicht-öffentlichen Repositories) oder eine gemeinsame
> GitLab Instanz, da wäre es super einfach Änderungen des anderen jeweils
> zu übernehmen.

Für die Nutzung solcher externen Dienste (auch mit nicht-öffentlichen 
Repositories!) muss aber vorab juristisch geklärt werden, ob es 
rechtliche Hindernisse gibt, z.B. bei Fremdsoftware. Dies ist eine sehr 
umfangreiche Thematik, die sehr viele Fragen aufwerfen und den Rahmen 
dieses Threads gewaltig sprengen kann.

Andreas S. schrieb:
> Alles Iditioten, außer Dir natürlich.

Schon hart Du lastest dem TO an, das er sich über Defizitte in seiner 
Firma aufreget, da er sich anscheinend Gedanken macht und etwas ändern 
will und selbst:

Andreas S. schrieb:
> Ich fand es ohnehin ziemlich fahrlässig, diesen
> Idioten damit zu beauftragen.

Andreas S. schrieb:
> Der Trottel hatte aber seine
> Sandbox gelöscht, so dass seine Quellcodes unwiderbringlich verloren
> waren.


Unabhängig davon, das Du mit Deinem geschriebenen ja recht zu haben 
scheinst, hat es beim lesen trotzdem einen gewissen Beigeschmack gehabt.

Das ganze Thema SW-Entwicklung mit mehreren Entwicklern war noch nie 
einfach und wird es auch nie sein. Es hat halt leider jeder seine 
Gewohnheiten und Arbeitsweisen und da wird ist es nie einfach alle unter 
einen Hut zu bekommen.

Ich kenne das auch, losgelöst von SW-Entwicklung, da ist der 
verantwortliche im Urlaub, Du darfst vertreten und siehst nicht durch 
vor lauter .sec und .org Dateien und Ordnern, weil man könnte es ja noch 
mal gebrauchen.

Dann versucht man sachlich auf die Probleme hinzuweisen und der jenige 
fühlt sich so an's Bein gepinkelt, das eine Diskussion über die 
tatsächlich vorhandenen Probleme nicht möglich ist und dem zu Folge die 
Probleme auch nicht gelöst wurden.

Natürlich waren die Probleme bekannt, aber man hat halt immer irgendwo 
händisch ein gegriffen und kein anderer wusste wo.

In dem Fall kam halt auch noch dazu, das man sich natürlich auch nicht 
erklären lassen wollte, wo die eigentlichen Probleme in der Basis lagen 
und wie man diese beheben hätte können, da hat man lieber irgendwelche 
Scripte angepasst und festgestellt, das es am Ende trotzem nicht ging.

Von dem her kann ich den TO schon verstehen, er will was ändern, hat 
aber einen Chef der scheinbar keine Weitsicht hat und Kollegen die 
Probleme nicht erkennen.

Dr. Sommer schrieb:
> Andreas S. schrieb:
>> Nein, nicht zwingend. Das funktioniert nur dann reibungslos, wenn alle
>> Beteiligten hinreichend kompatible Verzeichnisstrukturen verwenden.
> Ja logisch. Ich war mal davon ausgegangen, dass Leute die am selben
> Projekt arbeiten, die gleiche Verzeichnisstruktur nutzen. Das klappt ja
> bei tausend Open Source Projekten auch.

Einer unserer Kunden, mit dem wir sehr regelmäßig Lieferungen in beiden 
Richtungen austauschen, verwendet auf Grund einer internen Konventionen 
so unglaublich lange Verzeichnispfade, dass man darauf nicht sinnvoll 
entwickeln kann. Teilweise werden solche Pfade von Tools abgeschnitten 
oder gar nicht erst akzeptiert. Aus diesem Grunde arbeiten wir z.B. mit 
geschickt definierten svn:externals, d.h. zwecks Beibehaltung der 
kundenseitigen Verzeichnisstruktur gibt es die langen Pfade, aber für 
problematische Fälle eben auch die deutlich kürzeren Pfade als 
Referenzen.
>
> Andreas S. schrieb:
>> Damit werden aber auch die Checkins sichtbar, die eigentlich für die
>> andere Partei verborgen bleiben sollen.
> Nur die Commits die man dem anderen per pull/merge übergibt (und die
> "zwischen" den Ständen), nicht die aus anderen Branches.

Sobald man aber, wie es oben beschrieben wurde, nur noch einen einzigen 
Git-Server verwendet, werden alle Branches sichtbar, zumindest für den 
Administrator. Man kann natürlich auch noch an anderer Stelle, z.B. auf 
dem eigenen PC, noch weitere Repositories ablegen, aber diese müssen 
dann auch der Datensicherung usw. unterworfen werden. Technisch kann man 
bei Git o.ä. zwar beliebig viele Repositories verwenden, aber die Gefahr 
ist dabei auch sehr groß, dass wichtige Checkins verlorengehen. 
Spätestens dann, wenn z.B. Commits zur automatischen Generierung von 
E-Mails oder Aktualisierung von Tickets (z.B. bei Trac, JIRA) führen 
sollen, sollten die Repositories nicht zu sehr verstreut sind.

> Mir war aber aus dem originalen Posting nicht klar dass das ein Problem
> darstellt.

Du ahnst gar nicht, wie sehr Versionskontrollsysteme auch für 
"Firmenpolitik" missbraucht werden können. Damals als Angestellter kam 
irgendwann ein Produktmanager zu mir und befragte mich zu den 
Auswirkungen bestimmter Checkins, in denen ich die Struktur etlicher im 
Laufe der Zeit gewachsener C-Headerdateien deutlich aufräumte. Ich 
erklärte es ihm, aber wie zu erwarten war, verstand er es nicht. 
Daraufhin gab es eine Arbeitsanweisung an alle Entwickler, dass nur noch 
Änderungen eingecheckt werden dürfen, die unmittelbar die User 
Experience verbessern und den Shareholder Value maximieren. :-/

Von einem anderen Unternehmen ist mir bekannt, dass der dortige 
Betriebsrat vor dem Arbeitsgericht durchsetzte, dass Checkins und 
Bugtracker-Tickets keine Rückschlüsse mehr auf die beteiligten 
Entwickler zulassen dürfen, denn dies verletze die Persönlichkeitsrechte 
von Gewerkschaftsmitgliedern.

> Im Zuge des ganzen Cloud- und Saas-Hype hätte ich mal vermutet, dass das
> nicht mehr so das große Problem darstellt

Das mag in vielen Fällen zwar kein Problem darstellen, daraus auf eine 
Allgemeingültigkeit zu schließen ist jedoch nicht zulässig. Bei einem 
Kunden, der u.a. im Rüstungsbereich tätig ist und weltweit Standorte 
hat, geht es sogar so weit, dass es nicht zulässig wäre, (natürlich 
verschlüssselte) VPN-Verbindungen über Leitungen zu führen, die auf dem 
Staatsgebiet von Ländern verlaufen, mit denen keine entsprechenden 
militärischen Abkommen bestehen. Es ist nämlich rechtlich kaum ein 
Unterschied, ob man verschlüsselte Daten per LWL transportiert oder 
einen Konvoi mit schwerem Kriegsgerät durch ein Drittland transportieren 
möchte. Und nein, wir reden hier nicht über die technische Seite, 
sondern ausschließlich über die juristische und politische Seite.

> Viele Firmen verwenden fremde
> Hoster auch z.B. für e-Mail, Web & Co. GitHub bzw. Atlassian sind ja
> nicht irgendwelche Firmen.

Viele Firmen verwenden ausschließlich eigene Infrastruktur.

Und wiederum andere Firmen nutzen für manche Dienste ausschließlich 
eigene Infrastruktur und für andere auch Fremdleistungen, z.B. mein 
Unternehmen.

> Ich weiß auch nicht ob das rechtliche das
> eigentliche Problem ist - in den AGB der Anbieter heißt es ja dass die
> Daten geschützt sind. Die Frage ist mehr ob man es denen auch glaubt!
> Kommt es doch zum Datenleck, weiß man ja wen man verklagen kann.

Das hängt von Unternehmen zu Unternehmen ab. Teilweise werden sicherlich 
juristische Gründe vorgeschoben, um sich einfach die technischen Themen 
vom Hals zu halten. Aber in anderen Fällen verbieten eben bestehende 
oder noch zu schließende Verträge mit Kunden oder Lieferanten die 
Auslagerung der Daten an externe Dienstleister, insbesondere wenn diese 
anderen Rechtssystemen unterworfen sind oder unterworfen werden können. 
Gerade bei US-amerikanischen Unternehmen muss man ja sehr vorsichtig 
sein, weil die Geheimdienste eine so große Macht haben, dass die 
Unternehmen entsprechende Eingriffe weder publik machen noch sich mit 
rechtlichen Mitteln dagegen wehren können.