Masatake YAMATO <[EMAIL PROTECTED]> writes:
>> > 1. I think xtla-baz.el is not good name now.
>> > It should be called baz-xtla.el. Any objection?
>>
>> I'm not sure this is a good idea. tla and baz support are not
>> completely distinguishable. xhg is the support for hg, and names its
>> files xhg*.el, and similarly, xtla is the support for tla and baz, and
>> should name its files xtla*.el.
I second Matthieu's opinion here.
>> > 2. I think tla-dvc.el is not good name.
>> >
>> > We should rename it to xtla-dvc.el, or
>>
>> This is what we had originally, indeed but, this breaks `dvc-function'
>> which does a
>>
>> (require ...-dvc nil t)
>>
>> in case the function is not found. So the naming tla-dvc.el and
>> baz-dvc.el are more than conventions. They're needed for DVC to work.
>
> Stefan, what happens on xhg?
There is also xhg-dvc.el and cg-dvc.el. These files should implement the
bridging from xhg/cg functionality to the common dvc functionality.
>> > We should rename xtla-\(.+\)\.el to tla(match-string 1).el
>>
>> That's not very satisfying either, since you'd have baz related code
>> in tla*.el files.
>>
>> Let's say that xtla*.el is a common library this is used by tla-dvc.el
>> and baz-dvc.el which provide the DVC backends.
>
> Great idea.
>
> Here I summarize:
>
> Put tla and baz backend common code into xtla*.el. About *, I will try to
> decide.
> The non-common xtla*.el code will move to tla*.el.
Fine with me.
>> > 3. How do you think adding a new file named dvc.el.
>> > dvc.el do only require other dvc files like:
>> >
>> > (require 'dvc-core)
>> > (require 'dvc-unified)
>> > ...
>> >
>> > (provide 'dvc)
>> >
>> > So in backend, just (require 'dvc) is needed.
>>
>> No opinion on this.
>
> O.K. This is not small change. So I'd like to wait Stefan's comment.
> Of course, comments from the other developer are welcome.
>
> On Fedora(may be the same on Debian), /usr/include/glib-2.0/glib.h
> tells you what I'd like to say.
dvc.el is o.k. for me. But don't include xhg-dvc, baz-dvc, ...
The user should explicitly require the packages he wants to use.
>> > 4. Splitting xtla.el into smaller parts
>> >
>> > xtla is still too large. Is it o.k. to split them into
>> > smaller xtla-*.el files?
>> >
>> > How do you think?
>>
>> I think we should spend as little time as possible on Xtla. Bazaar 1.x
>> is being deprecated if not abandonned. tla is given a short second
>> life, but far superior alternatives are emerging, while tla doesn't
>> plan major evolutions, so ...
>
> Yes. However, `wc -l xtla.el' returns all most 10000 lines, which we designed
> and wrote. To make dvc core better, I strongly believe we can learn many
> things
> from the lines. I'd like try to reduce the lines to 6000 lines. Some of lines
> will
> go to dvc-*.el.
>
> Further more, dvc still depends on tla-*
> [EMAIL PROTECTED] cd dvc/lisp
> cd dvc/lisp
> cd: no such file or directory: dvc/lisp
> [EMAIL PROTECTED] export GREP_OPTIONS=
> export GREP_OPTIONS=
> [EMAIL PROTECTED] BACKENDS="xtla baz bzr xhg cg"
> BACKENDS="xtla baz bzr xhg cg"
> [EMAIL PROTECTED] for x in dvc*el ; do echo -n "${x}: " ; grep '.*' ${x}
> | sed -e 's/".*"//g'| grep tla- | grep -v "\"tla" | grep -v "^;" | wc -l;
> done
> < ; grep '.*' ${x} | sed -e 's/".*"//g'| grep tla- | grep -v "\"tla" |
> grep -v "^;" | wc -l; done
> dvc-about.el: 0
> dvc-autoloads.el: 121
> dvc-buffers.el: 0
> dvc-bug.el: 0
> dvc-cmenu.el: 0
> dvc-config.el: 0
> dvc-core.el: 0
> dvc-defs.el: 1
> dvc-diff.el: 20
> dvc-emacs.el: 0
> dvc-lisp.el: 0
> dvc-log.el: 0
> dvc-preload.el: 0
> dvc-register.el: 0
> dvc-revlist.el: 6
> dvc-site.el: 1
> dvc-state.el: 0
> dvc-status.el: 0
> dvc-tips.el: 12
> dvc-ui.el: 45
> dvc-unified.el: 0
> dvc-utils.el: 9
> dvc-version.el: 0
> dvc-xemacs.el: 1
> [EMAIL PROTECTED]
>
> Reorganizing xtla-*.el is one of the step to solve the dependencies.
I am not strong against the file splitting. But keep always in mind,
that more files increase the complexity as well. And there will always
be functions where it is not clear, in which file they belong.
Increasing the number of files also increases the number of these cases.
Stefan.
