Bernward Geschrieben 13. September 2009 report Geschrieben 13. September 2009 CVS ist lame. Nimm Subversion - da läuft ne BerkleyDB im Hintergrund. Sehr schön, vor allem wenn Du eine Historie bis 1991 in den Sourcen hast, die Du nicht verlieren möchtest.
obw Geschrieben 13. September 2009 report Geschrieben 13. September 2009 CVS ist lame. Nimm Subversion - da läuft ne BerkleyDB im Hintergrund. Sehr schön, vor allem wenn Du eine Historie bis 1991 in den Sourcen hast, die Du nicht verlieren möchtest. Das hatten auch andere und haben das genutzt.
Bernward Geschrieben 13. September 2009 report Geschrieben 13. September 2009 CVS ist lame. Nimm Subversion - da läuft ne BerkleyDB im Hintergrund. Sehr schön, vor allem wenn Du eine Historie bis 1991 in den Sourcen hast, die Du nicht verlieren möchtest. Das hatten auch andere und haben das genutzt. Werde ich mir merken. Eigentlich ist die Performance aber gut genug, ich habe nur den Verdacht, das irgendwelche locks spinnen.
Gast Geschrieben 13. September 2009 report Geschrieben 13. September 2009 Wir haben vor drei Jahren ein Repository mit ~15 Millionen Zeilen Code samt Historie migriert, allerdings von PVCS (würg) nach Subversion.
Bernward Geschrieben 13. September 2009 report Geschrieben 13. September 2009 Wir haben vor drei Jahren ein Repository mit ~15 Millionen Zeilen Code samt Historie migriert, allerdings von PVCS (würg) nach Subversion. Es scheint eher am Dateisystem zu liegen, ein find . -name '*lock*' kommt nicht durch
Gast Geschrieben 13. September 2009 report Geschrieben 13. September 2009 [Gedankenblase]Reboot oder Locks von Hand auflösen? ... Reboot oder Locks von Hand auflösen? ... Reboot oder Locks von Hand auflösen? ... Reboot oder Locks von Hand auflösen? ... Reboot oder Locks von Hand auflösen?[/Gedankenblase]
Gast Geschrieben 13. September 2009 report Geschrieben 13. September 2009 Es scheint eher am Dateisystem zu liegen, ein find . -name '*lock*' kommt nicht durch Guck mal, ob ein shutdown -r now durchkommt
Bernward Geschrieben 13. September 2009 report Geschrieben 13. September 2009 Es scheint eher am Dateisystem zu liegen, ein find . -name '*lock*' kommt nicht durch Guck mal, ob ein shutdown -r now durchkommt sicher, aber das würde ich auf dem Server auf dem neben vielen CVS Projekten auch einige SVN Projekte laufen sehr ungern machen
Meeresdruide Geschrieben 13. September 2009 report Geschrieben 13. September 2009 Sehr schön, vor allem wenn Du eine Historie bis 1991 in den Sourcen hast, die Du nicht verlieren möchtest. Das hatten auch andere und haben das genutzt. Wobei es evt. sinnvoller wäre, gleich auf git umzusteigen.Auch da gibt es Konvertierprogramme und die Verwaltung von Versionen ist nicht so eigenwillig wie bei SVN.
obw Geschrieben 13. September 2009 report Geschrieben 13. September 2009 Sehr schön, vor allem wenn Du eine Historie bis 1991 in den Sourcen hast, die Du nicht verlieren möchtest. Das hatten auch andere und haben das genutzt. Wobei es evt. sinnvoller wäre, gleich auf git umzusteigen.Auch da gibt es Konvertierprogramme und die Verwaltung von Versionen ist nicht so eigenwillig wie bei SVN. Ich empfehle für einen höchst subjektiven Featurevergleich den Google Tech Talk mit Linus Torvalds.
Meeresdruide Geschrieben 13. September 2009 report Geschrieben 13. September 2009 Ich empfehle für einen höchst subjektiven Featurevergleich den Google Tech Talk mit Linus Torvalds. Dem kann ich mich nur anschließen. Moment, ich suche mal den Link raus:
Kazzirah Geschrieben 23. September 2009 report Geschrieben 23. September 2009 Kommentierung im SAP-Standard-Code: " ABAP sucks !!! :-<<<<<
Stephan Geschrieben 23. September 2009 report Geschrieben 23. September 2009 Kommentierung im SAP-Standard-Code: " ABAP sucks !!! :-<<<<< Ah, du arbeitest mit dem BW
obw Geschrieben 28. September 2009 report Geschrieben 28. September 2009 pkg-config ist evil. Besonders, wenn es auf einem Rechner gefunden wird und auf dem anderen nicht.
Sulvahir Geschrieben 9. Oktober 2009 report Geschrieben 9. Oktober 2009 Was um alles in der Welt hat die Bundeswehr vor? "Ein /32–CIDR-Adressblock , wie in die britischen Kollegen beim RIPE beantragt haben, reicht uns nicht" => 2^96 (=79228162514264337593543950336 ) IP-Adressen reichen nicht? Wollen die jedem afghanischen Staubkorn eine IP geben?
Toro Geschrieben 9. Oktober 2009 report Geschrieben 9. Oktober 2009 Wellbrink Vortrag Anscheinend haben sie schon eine bestimmte Vorstellung davon wie die interne Hierarchie aussehen soll.
Nixonian Geschrieben 9. Oktober 2009 report Geschrieben 9. Oktober 2009 8 "theatres", da könnt ihr euch ja auf was einstellen. Dazu: "No nat on edge/peer routers", tja, das wären aber viel weniger. Noch dazu gehen die mit der maximalen Endanwender-Netzmaske (/48) auf die einzelnen Accesses. Da ist dann klar, daß ihnen ein /32 zu eng wird bei "nur" 65.000 Netzwerkeinheiten. Wobei: Man redet von Verschlüsselung (IPSEC?) da kann man auch private IP-Adressen tunneln genauso wie im vorgesehenen MPLS-VPN. Da braucht es gar kein geroutetes Netz. Vorstellung? Ja. More is better. So ziemlich der Alptraum des ambitionierten Netzwerkers, der liebevoll Adressen alloziert.
Sulvahir Geschrieben 10. Oktober 2009 report Geschrieben 10. Oktober 2009 Im Heise-Forum hat jemand versucht eine anschauliche Beispielrechnung aufzustellen.
Gast Geschrieben 10. Oktober 2009 report Geschrieben 10. Oktober 2009 Alternativ könnte man alle Atome des Universums adressieren (es gab ja mal die Schätzung, die von etwa 10^80 Atomen ausging)
Meeresdruide Geschrieben 11. Oktober 2009 report Geschrieben 11. Oktober 2009 Man braucht doch für jedes Atom ein /64. Schließlich muss man die Adresse ja von der MAC-Adresse des Atoms ableiten können.
Gast Geschrieben 11. Oktober 2009 report Geschrieben 11. Oktober 2009 Im Heise-Forum hat jemand versucht eine anschauliche Beispielrechnung aufzustellen. Die Argumentation wird aber wohl nicht als hieb- und stichfest erachtet: Das Menschliche Gehirn hat im Schnitt 15.000.000.000 Gehirnzellen. Es sei denn, du bist IT-Entscheider bei der Bundeswehr.
Sulvahir Geschrieben 12. Oktober 2009 report Geschrieben 12. Oktober 2009 Bei Microsoft sind die Daten in Gefahr. Beim Start des Upgrades habe es Probleme gegeben, es seien Daten gelöscht worden – und bei Danger gebe es kein Backup
Abd al Rahman Geschrieben 12. Oktober 2009 report Geschrieben 12. Oktober 2009 Microsoft nimmt Datenschutz halt ernst. WEas beschwerst Du Dich? Viele Grüße hj
Gast Geschrieben 12. Oktober 2009 report Geschrieben 12. Oktober 2009 Microsoft liegt damit nur im aktuellen Trend: Apples Snow Leopard frisst (manchmal) User-Daten
Abd al Rahman Geschrieben 12. Oktober 2009 report Geschrieben 12. Oktober 2009 Kein Wunder bei dem Firmenlogo Viele Grüße hj
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde Dich hier an.
Jetzt anmelden