Path: csiph.com!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: de.comp.lang.javascript Subject: =?UTF-8?Q?Re:_Aktion_beim_Schlie=c3=9fne_eines_Browserfensters?= Date: Mon, 17 Dec 2018 13:25:41 +0100 Lines: 67 Message-ID: References: <8ec1baef-ed6d-aad5-73df-b7c9dedfb099@PointedEars.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Trace: individual.net ZmmaIM2U/yvi/uLLbbqmWwa7wOqaZtnkELILF722jlIrFw1jq6 Cancel-Lock: sha1:8FE6NwPJMsWnJYiYeszbTKIZlAE= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com de.comp.lang.javascript:5006 Am 16.12.2018 um 21:22 schrieb Peter J. Holzer: > On 2018-12-14 10:34, Arno Welzel wrote: >> Arno Welzel: >>> Peter J. Holzer: >>>> Auf das exklusive Sperren verzichten und entweder ein Three-Way-Merge >>> >>> Ein Merge kann aber nicht auflösbare Konflikte verursachen, die man dann >>> als Benutzer klären muss. > > Kann. Passiert manchmal, aber meiner Erfahrung nach (als jemand, der > seit den 80er-Jahren Versionskontrollsysteme verwendet), recht selten. Dann hattest du eine behütete Kindheit. Alternativ: ich hab gelegentlich den Eindruck, dass svn und git vor Situationen kapitulieren, die cvs noch automatisch gelöst hätte. In Confluence haben wir zumindest recht häufig Merge-Konflikte gesehen, bevor auf den Live-Editor umgestellt wurde. In dem sieht man dann den anderen Nutzer schreiben. Usecases waren halt Dinge wie "User A macht eine Tabelle, User B+C+D+E fügen jeweils eine Zeile an". Davor kapituliert der Auto-Merge, weil er nicht weiß, in welcher Reihenfolge er die neuen Zeilen anfügen soll. Sowas passiert zwar bei Sourcecode auch, aber doch eher seltener. > Locks hingegen führen meiner Erfahrung nach (als jemand, der seit den > 90er-Jahren mit Windows-Applikationen auf SMB-Netzwerkfilesystemen zu > tun hat) mit großer Regelmäßigkeit zu Frustrationen bei den Usern. Hier führt das vor allem zu Gelächter in Besprechungen, wenn für einen Anhang zur Tagesordnung das Popup "Ist noch in Bearbeitung durch X" kommt. >>>> oder eine "Live"-Bearbeitung (a la Etherpad, Google Docs, etc.) >>>> implementieren. Aus Benutzersicht jedenfalls. Aus Entwicklersicht mag >>>> das angesichts dräuender Deadlines anders aussehen. >>> >>> Auch aus Benutzersicht mag es auch wenig sinnvoll sein, ein Dokument >>> permanent bei jeder Eingabe zu ändern, wenn man das versionieren will. >>> Ja, mir ist bekannt, dass Etherpad einzelne Änderung in seine Datenbank >>> schreibt. Das ist aber wenig hilfreich, wenn man z.B. von einem Artikel >>> einen Stand vor und nach einer redaktionellen Überarbeitung braucht. >> >> Ingrid weist mich auch noch auf den Widersprich hin, wieso "alle 30 >> Sekunden Server kontaktieren, damit die Session nicht ausläuft" falsch >> ist, aber "jede Änderung sofort zum Server schicken" dann "richtig" sein >> soll. > > Ich habe nicht behauptet, dass "alle 30 Sekunden Server kontaktieren, > damit die Session nicht ausläuft" falsch ist. Indirekt irgendwie schon, aber egal. > Ist habe behauptet, dass > das Sperren eines Dokuments zur Bearbeitung (fast immer) falsch ist. > Und wenn man ein Dokument sperrt, dann ist es ganz sicher falsch, die > Sperre aufzuheben, nur weil man 30 Sekunden kein Lebenszeichen vom > Client bekommen hat. Das kann aus diversen Gründen vorkommen, das wird > vorkommen, und wenn der User dann seine Änderungen verliert, ist er > frustiert. Deswegen würde ich in einem Weitverkehrsnetz nicht mit 30s-Timeouts arbeiten, sondern eher ein paar Minuten. Im LAN halte ich das für angemessen. Stefan