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

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

Re: Aktion beim Schließne eines Browserfensters

Show all headers | View raw

On 2018-12-17 12:25, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 16.12.2018 um 21:22 schrieb Peter J. Holzer:
>> On 2018-12-14 10:34, Arno Welzel <usenet@arnowelzel.de> 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.

So wie ich das geschrieben habe, war es wohl auch nicht richtig.

Ich glaube, man muss drei Arten unterscheiden:

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. 

Die dritte Art, wo man wirklich überlegen und oft noch in anderen Files
oder gar anderen Versionen nachsehen muss, um herauszufinden, wie man
das jetzt am besten bereinigt, ist sehr selten.

> 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 :-/.

>
> 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.

Das fällt vermutlich in Kategorie 2 oben. Die Software kann die richtige
Reihenfolge nicht wissen, für den Menschen ist sie meistens trivial. Und
der eigentliche Merge-Vorgang ist dann auch technisch wieder einfach.


> Sowas passiert zwar bei Sourcecode auch, aber doch eher seltener.

Ja, einer der "anderen Faktoren", die ich angespesprochen habe. Bei
manchen Dokumentarten sind überlappende bzw. benachbarte Änderungen
deutlich häufiger als bei anderen. Als Entwickler einer Applikation weiß
man das aber (hoffentlich).


>> 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.

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. 

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

Back to de.comp.lang.javascript | Previous | Next — Previous 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