Don't think so. From my own experience, long pages, with multiple headings/topics most often need to be edited as a whole. Usual practice is to put isolated metarial to the linked wiki pages. So, having to edit each section separately might become painful. My experience is to keep page sizes within reasonable limits ant splitting them as they grow.
Anyway, merging is simple to implement, elegant and complete solution for the case. Even simple, line-based diff-like merge, that could be implemented in a few hours, will close the issue. So far I've got a silly habbit to copy all the text to the clipboard before pushing submit :) -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Filipe Correia Sent: Tuesday, August 14, 2007 4:49 PM To: Trac Users Subject: [Trac] Re: НА: [Trac] Re: issue of concurrency in the trac wiki I believe merging will be less needed when this ticket is implemented: http://trac.edgewall.org/ticket/1024 Even if merges are still needed afterwards, I think they will probably bring much lesser problems. -- Filipe Correia On Aug 14, 1:02 am, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: > Possible, yes. Mind-numbingly difficult, also yes. Branch/merge > algorithms are one of the fields of computer science currently under > a huge amount of scrutiny. Writing a decent document merge system is > a thesis-level project (and I know someone doing just that). > > --Noah > > On Aug 13, 2007, at 7:53 PM, Sergey Chernov wrote: > > > > > Btw it could try to merge edits and let last editor to manually > > edit conflictis; e.g something like the svn. Much better than just > > discarding all the editing. And doesn't seem too hard to code anyway. > > > ----- Исходное сообщение ----- > > От: Noah Kantrowitz <[EMAIL PROTECTED]> > > Отправлено: 13 августа 2007 г. 22:15 > > Кому: [email protected] > > Тема: [Trac] Re: issue of concurrency in the trac wiki > > > Yes, the second (and subsequent) edits to the same base version will > > fail with an error. This is not a terribly good system, but it does > > at least prevent rollback edit glitches. > > > --Noah > > > On Aug 13, 2007, at 1:50 PM, [EMAIL PROTECTED] wrote: > > >> Folks, > > >> Has anyone dealt with the issue of concurrency in the trac wiki ? > >> Is there a "locking" mechanism available or at least a warning so > >> simultaneous sessions do not bonk one another ? > > >> Thanks ! > > >> Best Regards, > > >> Joe > > >> Joseph H. Dayney > >> Contract Software Engineer > >> Excel Resources > >> AppDev Team > > >> 435.755.4278 Office > >> 801.608.1052 Cell > >> 435.755.4210 Fax > >> 801-272-6615 SLC Home > >> [EMAIL PROTECTED] > > >> Moore Wallace, An RR Donnelly Company > >> 630 W 1000 N > >> Logan, UT 84321 > > >> CONFIDENTIALITY NOTICE: The information contained in this email > >> message is confidential and may be protected from disclosure. > >> Please be aware that any unauthorized use, printing, copying, > >> disclosure or dissemination of this communication may be subject to > >> legal restriction or sanction. If you think you have received this > >> email message in error, please reply to sender. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
