Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.javascript > #5008

Re: Aktion beim Schließne eines Browserfensters

From Stefan Reuther <stefan.news@arcor.de>
Newsgroups de.comp.lang.javascript
Subject Re: Aktion beim Schließne eines Browserfensters
Date 2018-12-22 11:56 +0100
Message-ID <pvl8oo.20c.1@stefan.msgid.phost.de> (permalink)
References (9 earlier) <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>

Show all headers | View raw


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

Back to de.comp.lang.javascript | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Aktion beim Schließne eines Browserfensters Ralph Stahl <post@rstahl.de> - 2018-12-05 14:37 +0100
  Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-05 22:35 +0100
    Re: Aktion beim Schließne eines Browserfensters Ralph Stahl <post@rstahl.de> - 2018-12-06 14:24 +0100
      Re: Aktion beim Schließne eines Browserfensters "Christoph M. Becker" <cmbecker69@arcor.de> - 2018-12-06 15:35 +0100
      Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-06 17:21 +0100
      Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-06 18:57 +0100
        Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-06 21:22 +0100
          Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-07 19:47 +0100
            Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-07 20:22 +0100
              Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-07 21:17 +0100
                Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-12-14 00:03 +0100
                Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-14 11:33 +0100
                Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-14 11:34 +0100
                Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-12-16 21:22 +0100
                Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-17 13:25 +0100
                Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-12-20 13:32 +0100
                Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-22 11:56 +0100
                Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2019-01-02 13:22 +0100
                Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2019-01-03 08:50 +0100
                Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-14 18:56 +0100
                Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-15 12:48 +0100
                Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-12-16 21:43 +0100
              Re: Aktion beim Schließne eines Browserfensters Jan Novak <repcom@gmail.com> - 2018-12-10 10:02 +0100
                Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-10 21:26 +0100
    Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-07 21:09 +0100
  Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-07 21:13 +0100
    Re: Aktion beim Schließne eines Browserfensters Ralph Stahl <post@rstahl.de> - 2018-12-10 10:46 +0100

csiph-web