I responded to this a few days ago, but it hasn't shown up on the list
yet, so I'm responding again.

On a related topic, the archive at
https://mail.gna.org/public/dvc-dev/2007-04/index.html is (at least)
several days behind (it doesn't have this message from Christian, for
example); is that typical?

Christian Ohler <[EMAIL PROTECTED]> writes:

>> I'm considering switching to the monotone CM system, but was stymied
>> by the lack of Emacs support (I'm currently using cvs and Emacs
>> pcl-cvs).
>
> Have you tried contrib/monotone.el in monotone's source tree?  It's a
> lot more primitive than DVC, but may be worth a look, too, depending
> on your needs.

I did try that.

I'm used to pcl-cvs, which (with the right option settings) displays a
list of all the files that need some sort of attention; need-update,
modified, unknown.

>> xmtn-readme.txt seems to imply that dvc-diff should
>> show the unknown files, so they can be added or ignored (as
>> cvs-examine does with pcl-cvs).
>
> As far as I know, dvc-diff is not supposed to show unknown files (just
> like mtn diff doesn't show them).
>
> If you have any suggestions on how to disambiguate the readme file on
> this, please let us know.

This paragraph:

    C-x V s shows the status buffer. This currently shows modified,
    renamed and unknown files. I don't use it much, C-x V = seems
    preferable.

led me to think dvc-diff would show unknown files. Perhaps it could be
expanded:

    C-x V s shows the status buffer. This currently shows modified,
    renamed and unknown files, but does not allow operations on them.
    I don't use it much, C-x V = seems preferable (although it does
    not show unknown files).

> The equivalent of cvs-examine that you're looking for is supposed to
> be dvc-status.  However, xmtn only implements this in a very
> rudimentary way (non-interactively) because there is no basic_io
> variant of mtn automate inventory yet; this was being worked on but
> hasn't appeared so far.  This, together with the fact that dvc-diff
> already offers a similar interface, makes a proper dvc-status a low
> priority for me.
>
> An alternative way to improve dvc-status for monotone would be adding
> an automate inventory parser to xmtn and implementing dvc-status on
> top of that; but waiting for a basic_io variant of automate inventory
> seems preferable because it avoids the effort of writing and
> maintaining a (non-basic_io) automate inventory parser.

I've read the monotone manual on automate, and I think I understand
what you are saying.

I gather you feel a basic_io version of 'automate inventory' would be
easier to parse, or perhaps contain more information?

I've joined the monotone devel list; I'll ask there about the status
of this. It's been a while since I've done C++ hacking (I use Ada
full-time), but perhaps I can contribute.

>> I've hacked on Emacs lisp quite a bit, so I can help improve some of
>> this. But I'm not used to common lisp. Is there a good common lisp
>> reference/tutorial I can read?
>
> xmtn is in fact written in Emacs Lisp, with the extensions provided by
> (require 'cl), which only adds some Common Lisp features to Emacs Lisp
> but is not a full Common Lisp implementation.

Right. I've now discovered the Emacs info node on the common lisp
extensions; I'll read that.

> Your patches are welcome even if they don't match my style.  Are you
> having trouble understanding xmtn's code?  Which parts?

I have not looked at it much yet; I'm just anticipating trouble :).

I did run the Emacs debugger on dvc-diff, trying to understand an
error message I was getting (it turned out to be a monotone database
issue). I noticed that the macros that create defuns confuse or defeat
the Emacs lisp help system ("can't find xmtn-foo in *.el"). I do
understand those macros make the code easier to write, but they make
it harder to understand.

-- 
-- Stephe

_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev

Reply via email to