Quali metodi usano i wiki per unire le modifiche simultanee?

Question

Se due utenti modificano lo stesso argomento wiki, quali metodi sono stati utilizzati nei wiki (o in un simile software di editing collaborativo) per unire le modifiche del secondo utente con il primo?

Vorrei una soluzione che:

• non richiede il blocco
• non perde alcuna aggiunta alla pagina.
• Potrebbe aggiungere ulteriori "boilerplate" testo per indicare dove sono state apportate diverse modifiche.

(Sono interessato a una soluzione che potrebbe essere utilizzata per implementare questa idea di uservoice per overflow dello stack.)

Answer 1

TWiki si fonde automaticamente Modifiche simultanee .

  

TWiki consente più modifiche simultanee dello stesso argomento, quindi unisce automaticamente le diverse modifiche. Probabilmente non noterai nemmeno che ciò accada a meno che non ci sia un conflitto che non può essere unito automaticamente. In questo caso, potresti vedere TWiki che inserisce " segni di modifica " nel testo per evidenziare i conflitti tra le tue modifiche e quelle di un'altra persona. Questi segni di modifica vengono utilizzati solo se modifichi la stessa parte di un argomento di qualcun altro e indicano come appariva il testo, quali erano le modifiche dell'altra persona e quali erano le tue modifiche.

     

TWiki avviserà se si tenta di modificare un argomento che qualcun altro sta modificando. Avvertirà inoltre se è stata richiesta un'unione durante un salvataggio.

C'era anche un po 'di documentazione da quella funzione che veniva sviluppata dettagliatamente come si comporterebbe.

  

I principi di base che ho usato per codificare l'algoritmo di unione erano:

     

  
1. Se è possibile unire senza utilizzare gli indicatori di conflitto, farlo.
  
2. Se è possibile unire utilizzando gli indicatori di conflitto, farlo.
  
3. Se non è possibile unire, vince il check-in più recente.
  

Vale la pena notare che TWiki ha una funzione simile a Stack Overflow per far collassare le successive revisioni dello stesso utente entro un certo limite di tempo e questo ha provocato un errore quando si verificava in combinazione con un'unione .

  

  
1. Utente A modifica argomento
  
2. L'utente A salva rev N
  
3. L'utente B modifica l'argomento, raccoglie rev N
  
4. L'utente A modifica nuovamente l'argomento, raccoglie rev N
  
5. L'utente A salva le modifiche; save vede che la modifica è all'interno di ReplceIfEditiedWithin? finestra, quindi non aumenta il numero di giri
  
6. L'utente B salva, il codice rileva che il numero di giri sul disco non è cambiato da quando ha iniziato la modifica , quindi non rileva la necessità di unire.
  

Vale anche la pena notare che TWiki avviserà il secondo utente che l'argomento è in fase di modifica:

  

Così ho inventato il concetto di "leasing". Quando un argomento viene modificato, viene assunto un lease sull'argomento per un periodo di tempo fisso (impostazione predefinita 1h). Se qualcun altro prova a modificare, gli viene detto che esiste già un lease sull'argomento, ma ciò non impedisce loro di modificarlo. Non è un lucchetto, è solo un modo di consigliarli. La fusione è ancora il meccanismo di risoluzione principale; il contratto di locazione è puramente consultivo. Se un utente - o un plug-in - sceglie di ritirarsi da un argomento perché qualcuno ha un contratto di locazione su di esso, beh, dipende dal plug-in.

     

Il commento descrittivo in TWiki.cfg è il seguente:

   # When a topic is edited, the user takes a "lease" on that topic.
   # If another user tries to also edit the topic while the lease
   # is still active, they will get a warning. The warning text will
   # be different depending on whether the lease has "expired" or
   # not i.e. if it was taken out more than LeaseLength seconds ago.

nota che la terminologia del leasing è solo per gli sviluppatori, non per gli utenti finali.

Answer 2

La mia esperienza con la maggior parte dei software Wiki (ad esempio MediaWiki) è che tiene traccia della versione del documento che stai modificando. Se il documento cambia durante la modifica del tempo, la modifica viene rifiutata e viene richiesto di eseguire un'unione manuale.

Answer 3

Puoi scrivere un " lock " in un'altra tabella di database con l'id dell'utente e l'ora e cancellare il "blocco" (che non è un vero blocco per coloro che non capiscono) quando la persona salva o dopo x minuti.

In questo modo, quando qualcuno prova a modificarlo e qualcuno lo sta già facendo. Un messaggio può apparire con il tempo rimanente O semplicemente dicendo che qualcun altro sta attualmente modificando il post.

Answer 4

Bene, potresti usare un algoritmo di fusione, come quello usato dal software di controllo del codice sorgente. Probabilmente vorrai farlo verificare le modifiche a livello di paragrafo, per aiutare a mantenere la leggibilità.

In caso di potenziale conflitto (ad es. due utenti che modificano lo stesso paragrafo), probabilmente dovrai semplicemente presentare entrambe le versioni con il testo del bollettino e / o notificare al secondo e ai successivi autori che il contenuto del loro post potrebbe essere cambiato da ciò che hanno inviato.

Answer 5

Bene, ora penso che sarebbe un'idea terribile, terribile. Siamo onesti: la fusione è piuttosto rischiosa nel codice e almeno ha elementi che potrebbero essere isolati. Non farlo: l'intelligenza umana sarà sempre migliore. Invece stai cercando di sostituirlo con una soluzione automatica che può risultare in un output non sano, senza alcun vantaggio.

Answer 6

Nella ricerca della risposta TWiki mi sono anche imbattuto in SynchroEdit che sembra essere un SubEthaEdit editor multiutente simultaneo basato su browser. Sembra che potrebbe essere stato abbandonato verso settembre 2007, ma è disponibile per il download il codice sorgente.

Answer 7

Per ragioni di documentazione: DokuWiki inserisce un blocco di 15 minuti nelle pagine modificate, che si rinnova ogni volta che visualizzare in anteprima le modifiche (ad es. 15 minuti dall'anteprima o iniziare la modifica).