Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Stefan Reuther <stefan.news@arcor.de>
Newsgroups: de.comp.lang.javascript
Subject: =?UTF-8?Q?Re:_Aktion_beim_Schlie=c3=9fne_eines_Browserfensters?=
Date: Sat, 22 Dec 2018 11:56:07 +0100
Lines: 78
Message-ID: <pvl8oo.20c.1@stefan.msgid.phost.de>
References: <g6q2k9F85knU1@mid.individual.net> <c84c6ac7-fb97-bd45-e65e-b6c342e70a22@PointedEars.de> <g6sm8cFpivpU1@mid.individual.net> <pubrei.11c.1@stefan.msgid.phost.de> <f0fae197-e237-2f90-2905-7204e2722b8e@PointedEars.de> <pueiog.40k.1@stefan.msgid.phost.de> <8ec1baef-ed6d-aad5-73df-b7c9dedfb099@PointedEars.de> <g702r9Fhv11U1@mid.individual.net> <slrnq15paf.acc.hjp-usenet3@hrunkner.hjp.at> <g7hf7gFcdbpU1@mid.individual.net> <g7hfa0FcdbpU2@mid.individual.net> <slrnq1dd0d.ki1.hjp-usenet3@hrunkner.hjp.at> <pv884m.4pg.1@stefan.msgid.phost.de> <slrnq1n2vq.2pu.hjp-usenet3@hrunkner.hjp.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Trace: individual.net cQrz8QoVhp5x344HuZz2gAJV3FfvRmEemIMaQjim3JsUrBhygT
Cancel-Lock: sha1:71AVMnlbMVL/kmAl5sUECymOEAg=
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: <slrnq1n2vq.2pu.hjp-usenet3@hrunkner.hjp.at>
Xref: csiph.com de.comp.lang.javascript:5008

Am 20.12.2018 um 13:32 schrieb Peter J. Holzer:
[Lock vs. Merge]
> 1) Merges, die die Software vollautomatisch durchführen kann (inklusive
> Konflikten, die sich automatisch auflösen lassen)
> 
> 2) Merge-Konflikte, die die Software nicht auflösen kann, die aber für
> den Benutzer trivial sind.
> 
> 3) Merge-Konflikte, die auch für den Benutzer nicht trivial sind.
> 
> Die erste Art ist meiner Erfahrung nach mit Abstand die häufigste. Ein
> "git merge" läuft in der weit überwiegenden Zahl der Fälle (sicher über
> 90 %, aber genauer kann ich das nicht sagen) problemlos durch, obwohl
> ich ziemlich exzessiv Branches verwende (gestern habe ich z.B. bei einem
> Projekt 5 Branches aufgemacht, die ich heute alle wieder in den Master
> mergen werde).
> 
> Die zweite Art ist viel seltener, kommt auch auch noch recht regelmäßig
> vor. Das ist allerdings die Art, die man in einem Web-Interface auch in
> einer Weise präsentieren kann, die auch Arnos sprichwörtliche Oma nicht
> vor Probleme stellt. 

Selbst, wenn man sich auf die ersten zwei Fälle beschränkt: das erhöht
die Komplexität der Software *und der Nutzerführung* um Größenordnungen.

Für 1) muss ich überhaupt erstmal einen Merge-Algorithmus haben - und
sei es, dass ich meine Daten in eine Form bringe, dass ein
Standard-Merge-Tool damit umgehen kann. Wenn das, was ich da editiere,
kein reiner Text ist, ist das schon mal nicht trivial.

Für 2) muss ich eine Benutzerführung bauen, die dem Nutzer verständlich
anzeigt, was er da tun muss (wie stelle ich dar, dass der konkurrierende
Bearbeiter das Wort fett gemacht hat, welches ich unterstreichen
wollte?). Ich muss damit umgehen können, dass während der
Konfliktauflösung ein weiterer Bearbeiter den Text editiert.

Damit hast du aus dem "Nutzer müssen in der Lage sein, Artikeldetails
über die Webschnittstelle bearbeiten zu können" aus dem Dreitages- ein
Dreimonatsprojekt gemacht.

Mit Locking: ganz normales Editierfeld. 'setInterval(function(){ new
XmlHttpRequest(...).send() }, 30000)' (oder gar ganz ohne Javascript,
<iframe> mit Refresh-Intervall). 'if (time() < $db->{time} - 100)'. Fertig.

>> Alternativ: ich hab gelegentlich
>> den Eindruck, dass svn und git vor Situationen kapitulieren, die cvs
>> noch automatisch gelöst hätte.
> 
> Ich mag mich täuschen, aber meiner Erinnerung nach war, CVS nicht
> besonders gut darin, Konflikte aufzulösen. Ich sogar mal ein Script
> geschrieben, das die oft exzessiv großen Konfliktbereiche minimiert.
> 
> Subversion war nur wenig besser. Git ist deutlich besser. Mit git
> gehört Branching und Merging für mich zum Arbeitsalltag und auch die
> Kollegen nutzen es. Mit Subversion war jeder Merge eine sorgfältig
> geplante Aktion und die Kollegen haben das gerne mir überlassen :-/.

git hat vor allem rebase, mit dem man den Merge-Aufwand schön in kleine
Stücke schneiden kann...

>> 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.
> 
> Es gibt auch Gründe, die wenig mit der Netzwerkverbindung zu tun haben.
> Von durch eine andere Webapplikation lahmgelegten Browsern bis zu
> Leuten, die ihr Notebook zuklappen, um ins Besprechungszimmer zu gehen. 

Das wäre dann die philosophische Frage, ob man in diesem Usecase das
Lock aufrechterhalten will, oder ob man den Nutzer einfach aus der
Editorsitzung rauswirft (Status vielleicht als noch nicht
veröffentlichten Entwurf speichern und dem nächsten Bearbeiter
präsentieren) und ihn sich nach Wiederankunft in der Zivilisation eine
neue machen lässt.


  Stefan