Várj, tehát a módosítás utáni svn commit alapján kimondod, hogy ezt én basztam el? Ez komoly?
Nézd, én direkt rákérdeztem, hogy van-e használatban bármilyen tool, amivel az inkriminált fájlok kezelve vannak. Azt írtad, hogy semmi ilyesmi nincs, most meg kiderült, hogy mégis van egy subversion, ahol és amivel a fájlok kezelve vannak, amelyek változtak. A leírtak és hozzáírtak alapján még mindig úgy gondolom, hogy a legerősebb lábakon az a feltételezés áll, hogy a te oldaladon van valami bug vagy side-effect a környezetben, ami időnként megszopat.
hogy ők soha nem csinálnak ilyet ( vártam is), nem tudnak ilyen hibáról
De most komolyan, mi előnyük származik belőle, hogy miközben csak törekednek 99,9 százalékos rendelkezésre állásra, vagyis ennyit se kell biztosítaniuk és nincs semmi következménye, ha elveszítik a teljes storage tartalmat, akkor is ilyen fondorlatos hülyeségekkel szopatják az ügyfeleket, hogy visszaállnak a fájlrendszerrel vagy egy részével egy 1-3 héttel korábbi állapotra és a virtuális gép ebből nem vesz észre semmit? Eközben pedig minden szarért le kell állítani a gépeket: ha bővítenél, le kell állni; ha korrekt snapshot kell, le kell állni; ha módosítasz a placement group beállításokon, le kell állni; ha hozzáadnál volume-ot, le kell állni; ha törölnél volume-ot, le kell állni; hardver csere miatt relocation van, le kell állni; és a többi.
Meg ezen felül az is gyanús, hogy más se tud ilyen hibáról... nyilván nem zárható ki, hogy ők basztak el valamit, de minden jel arra mutat, hogy a hiba inkább nálad van.