2013/10/23 Edward K. Ream <edream...@gmail.com>: > On Tue, Oct 22, 2013 at 8:35 AM, Zoom.Quiet <zoom.qu...@gmail.com> wrote: > >> How to support Leo user can work with own organizer nodes in Team? > > The Leo community must acknowledge that problems do exist. Having said > that, the problems aren't as big as some people say. >> >> >> of course, the problem had difference background: >> 1. the Team is all Leo user >> 2. the Team is only one Leo user >> 3. the Team is some Leo user > > > If everyone uses Leo, there is not much of a problem, because everybody > wants can live with sentinels and use @file. > > Situations 2 and 3 are similar, because those who don't use Leo, no matter > how many there are, will complain if Leo users insert sentinels. >
... > > My conclusions are as follows: > > 1. If all else fails, you can always use @edit for shared files. This won't > be fun, but it's equivalent to using Emacs. BTW, neither vim nor Emacs is > free from difficulties when using shared files. SCCS conflicts will happen! > And of course, for shared files that are changing quickly, you can just use > a plain text editor. > @edit is new command for me, but in try: - "@edit nodes must not have children" - Huuu this is realy not fun. > 2. @auto isn't great, but if you are going to do a lot of editing on a > shared file, you can use @auto to import the file, change @auto to @file > while you work, and then to @nosent to write the file just before you commit > it. > > 3. @shadow should work properly for shared files, even though the @shadow > algorithm will make "bad guesses" and put lines in the wrong nodes. Bad > guesses do **not** affect the external file. > > I call this **the fundamental @shadow theorem**. Bernhard Mulder may > understood that @shadow is sound, but he never stated the theorem. When I > understood that the theorem was needed, it was quite easy to prove it. > @shadow became an official part of Leo only after I saw that @shadow is > *completely* sound. > sorry for my poor Cnglish, should i re-describe my problems, maybe can hold another **the fundamental @cooperate theorem** just flowing the normal cooperate process: 0. create new nodes or load from out file - yes, @auto is work great in this step 1. edit/notice/refactory... in Leo - yes, we love this feeling, everything is nest nodes 2. export source code files - yes, @shadow is can cover mostly conditions 3. through git/hg/svn sharing us work, after local tested 4. through git/hg/svn sync teammate's work 5. merge others fixed into Leo nest nodes loop begin step 1. so flowing this kind of nature team cooperate process, there is one core problems: in setp 5. there is no way to merge others fix into own organizer nodes?! - because programming base sooo persnally think - we need usage persnal .leo file in team - to recoder persnal snips/noted/notice... etc. - if base @shadow : - anyone save Leo, will export into same named .leo_shadow/x*.* - so through VCS , other teammate usage "Read @shadow nodes" - will flush persnal own organizer nodes as other guys who is the last commit change sets! - means base Leo merge teammate fix, there is not any chance to pre-merge local edit ? - even usage especial flow can merge local edit in first - it slao can not solve the "own organizer nodes" problem - in fact , one same class/function is different block relation understand - just Leo support us can recoder our understand as "own organizer nodes", make people love Leo - if @shadow force teammate base same nest nodes to read/think same files - that is same others IDE'e environment , such as:"Visual Studio" that all. my core puzzled just : How to keep "own organizer nodes" in team cooperate? in fact, github gived one perfect solution: "Pull Requests" - so i guess if base @shadow support local "Pull Requests" will realy happy - the different .leo will export different .leo_shadow/x*.* e.g - matter1.leo @shadow hallo.py export .leo_shadow/matter1x*.* - matter2.leo @shadow hallo.py export .leo_shadow/matter2x*.* - when "Read @shadow nodes" - Leo can base the shadow files report us as "Pull Requests" - and base some litter merge action/choice - others fix will installed "own organizer nodes" that is probability? > Edward > -- 人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦! KM keep growing environment culture which promoting organization be learnning! 俺: http://about.me/zoom.quiet 许: http://creativecommons.org/licenses/by-sa/2.5/cn/ -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.