dorty

seis drum .. sag ja da kann man drüber diskutieren und und und .. bei uns funzt das wunderbar (wir sind der meinung, das sogar besser als mit scm oder co.) klar wenn man seine projekte schlecht strukturiert brauch man so oder so ein scm ... oder wenn man gigantische quelltexte hat .. aber wiegesagt wir arbeiten sowieso modular weshalb der fall das zweileute am selben fall arbeiten schlicht nicht auftritt, wenn dies passieren können würde hätte einer von beiden blödsinn gemacht .. das hätte auch keinerlei konseq. außer das er das fremd-modul welches erverändert hat nachträglich auf dem server anpassen müssten ... aber egal ... egal ... *g* ich muss nu meine neue idee durch denken *g*

@wiggum: jup rsync triffts relativ gut ... nur eben noch eine ecke rafinierter durch das aktive monitoring.

nein lizzy ... zu 1: selbst verstündlich kann man zwischenstände speichern ... diese 5min. sind der autosave bei IDLE zu 2: die festplatten (sata) haben natürlich deutlich mehr power als 600 kb/s *g* die 600 kb/s entstehn durch die fast schon Random-Read-Zugriffe des Compilers ... (gib mir zeile aus quelltext ... gib mir zeile 1 von verwendeter komponente im quelltext ... etc ... das schleicht schon brutal ..) durch die ramdisk wird die unfähigkeit der festplatte 500mb (gesamt projekt volumen) auf einmal zu cachen übergangen zu 3: wusst ich nicht *seufz* ich hab da nur gelesen "projekt umfang von max. 70h .." und zu 4: mhm ... da könnte man jetzt drüber diskutieren ohne ende ... aber für uns erfüllt es schlicht keine funktion die wir brauchen ... unsere software ist und wir so entwickelt das es komplett überflüssig ist .. wir arbeiten niemals an ein und dem selben file geschweigeden am selben modul...blabla... aber zu deiner beruhigung *g* wir sichern den code täglich auf 6 versch. geräte (inkl. dezentralerSicherung). egal .. sag ja da könnte man ewig rumdiskutieren ... [darum sollte es im projekt ja auch nicht gehn *g*] nein nein .... ich werd mir was anderes überlegen (hab nur keine gescheide idee) ... was mich so ärgert ist das jeder schreiner als prüfstück ein schrank baut und als fachinformatiker man nicht einfach mal sagen kann ich bau ein hexeditor ... das bissel gestört ... na trotzdem an alle ein herzliches danke schön

achja .. ein anderer compiler geht natürlich nicht ... da wir in delphi/pascal programmieren gibt es keine alternativen compiler die auch nur ansatzweise dieses level bieten. (sind sozusagen compiler-gebunden *g*)

also ... der hebel an dem compiler der fehlt .. fehlt leider wirklich .. der compiler erlaubt es nicht den einlese-buffer zu erhöhen ... klar könnte ich den compiler decompilen und umschreiben aber dafür reicht die projekt arbeit lange nicht. ähm zu unternehmenskritschedaten + stromausfall etc. ganz klar wenn der strom weg ist etc. sind die daten der ramdisk auch weg .. das der punkt an dem mein tooly ins spiel kommt es überwacht die ramdisk via file-monitoring und bei der kleinsten änderung werden diese auf den server geschreiben ... (speichern eines sourcecodes über strg+s zB etc.) also max. auftrettende datenverlust beläuft sich auf *denk* 5min. idle time beim autosave. damit könnten wir locker leben ... es handelt sich nicht um kundendaten oder andere daten die nicht wieder herstellbar wäre ... zumal eine erneute-programmierung der verlorenen 5min. beim nächsten compile bereits wieder eingespart wären. (ausgehend davon das alle usv's versagen etc...) das der punkt wo eben solid-state-disks besser wären ... (aber halt auch schweine teuer bei der leistung die wir brauchen, diese aber genauso aufs netz aufgespielt werden müssten [wäre dann aber sozusagen zeitunkritisch])

also ... nein die 150 mb sind nicht reiner sourcecode (das sind ca. 10~20mb [natürlich mit 3't sourcen]) und beim compilen werden natürlich OBJ-Files sowie tonnen weisse Debug-Files erzeugt .. die finalle exe hat ca. 30 mb ... die compiler einstellungen + optionen können wir nicht ändern (leider) unsere produktionsschritte werd ich hier jetzt nicht bis ins detail erklären aber es ist erforderlich das der sourcecode konstant auf dem server gesichert wird. (lokales arbeiten ohne ramdisk, also auf der festplatte, sind nur grade mal doppelt so schnell wie die netzlaufwerke ... [also schlicht auch noch zu lahm] na die zeit von 50h ist ja nur geschätzt .. je nach aufwand könnte ich die entwicklungszeit locker auf das doppelte aufblasen *denk, grübel, überleg* scm, cvs etc.. nee .. wir sind eine 3 coder firma da tun wir uns mit sowas nicht rumschlagen *g* (wir proggen modular und fügen diese dann zusammen) mhm ... doof ich fand die idee ganz nett .. aber ich seh schon es ist schwer das rüberzubringen. (ich mein mal ehrlich wir sparen da pro jahr ca. im schlimmsten fall 300 h im besten über 2000 h ... wenn das kein sinnvolles ding ist *g*) nagut muss ich nochmal überlegen ob ich was "anspruchsvolleres + leicheter verständliches finde (bringt ja nix wenn ich dann 2h brauch um zu erklären was das ding macht)

also ich werde die Software schreiben welche den Datentransfer von der RamDisk auf den Server übernimmt (dort liegt der von der RamDisk rückgesicherte SourceCode welcher dort via RAID + Backup-System täglich gesichert werden muss) Da der Compiler aber langsam ist können wir nicht auf dem Netz-Compilen sondern brauchen eine insbesondere extrem schnelle lösung. deshalb die ramdisk, das problem diese ist ja flüchtig .. das programm welches ich schreiben werde, würde zB erkennen wenn eine neue datei in der ramdisk liegt bzw ein neuere und diese dann wenn die CPU-Last zB unter 20 % liegt oder mehr als 5min. vergangen sind oder der Client-PC hinterunterfährt auf den Server übertragen. Das heisst die Software muss die RamDisk-Überwachen und die Änderungen der dortigen Files möglichst schnell auf den Server übertragen, ebenso beim arbeitsbeginn muss die Software ein Projekt-Verz. vom Server in die RamDisk übertragen. Zeitplan *denk* mal ausm bauch raus: 1. Analyse - 4h Besprechung mit Kunden - 2h RamDisk/Solid-State & Co. Produkt vergleich bewertung. - 2h 2. Entwurf Konzeptionierung + Planung - 2h 3. Implementierung Installation Test-System - 1h Entwicklung - 24h 4. Testen Test-Planung: 1h Test-Durchführung: 2h Revision: 2h 5. Dokumentation 14 h Anwenderdokumentation 6 h Projektdokumentation 8 h ----> ca. 50 h (müsste ich mir zwar nochmal genau durch rechnen .. aber das müsste hinkommen) also die herrausforderung liegt in der programmierung einer intelligenten synch.-software zwischen RamDisk und Netzlaufwerk. ( zubillig? ) (** Das Problem ist das wir in der Firma keine Kunden-wünsche/Aufträge direkt umsetzen .. also muss ich so oder so eine standalone-app. schreiben **)

Hallo erstmal, also mein idee ist die folgende (weil wir es auf arbeit vermutlich eh bald brauchen): Grob: Ein Compiler-RamDisk-Cache-Synchronizer (lang und unverständlich *g*) Also wir entwickeln software in Delphi und dabei wälzt der Compiler ca. 150 mb übers netzwerk (gigabit-netz) das ganze dauert in etwa 3~7 min. (je nach projekt-grösse) .. (liegt daran das der compiler nur byte-weise liesst und dadurch die datenrate bei ca. 300 kb/sekunde liegt) also das ist ultra-lahm ... also dachten wir laut über solid-state-disks und ramdisks nach ... nun dacht ich mir das wäre doch ein schönes projekt wenn ich das für eine ramdisk realisiere. d.h. Die Software synch. (auf verschiedene überwachungs-ereig.) die Daten in der RamDisk mit dennen auf dem Server dadurch sinkt die warte zeit von einem 7min. normalen compile auf ca. 1min. (da wir zu 3't jeden tag ca. 40~70x mal compilen und zeit bekanntlich geld ist ...) aufjedenfall könnte ich die preise für RamDisk-Software und Solid-State-Disk vergleichen sowie vor/nachteile ... das ganze hat ein gewissen anspruch (daten-synch. beim starten projekt-verz. in ram kopieren etc.) also bwl mässig sowie programmatisch wäre da einiges drin, genauso wie eine produkt-besprechung etc.. (kann ja so tun als hätte ich es für einen kunden entwickelt ... die besprechung findet ja dann sowieso mit meinen chefs statt *g*) was denkt ihr darüber? MfG Dorty (FIAE)