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.
