Christian Ohler <[EMAIL PROTECTED]> writes:
> The file docs/DVC-API defines the term "revision identifier" as follows:
>
>> We define a unified way to designate a revision in lisp,
>> which we call revision identifiers, or rev-id:
>>
>> REVISION-ID :: (<dvc> BACK-END-ID)
>> ;; <dvc> is one of 'tla, 'bzr, 'xhg, ...
That's definitely a mistake (which I claim the authorship of ;-) ).
To make it clear, what bzr calls "revision specifier" is what monotone
calls "selectors" ('just checked the doc:
http://monotone.ca/docs/Selectors.html )
I don't care whether we call our data structure "selector" or
"revspec", but "revision ID" is definitely a mistake.
> This makes DVC's (last-revision ...) and (previous-revision ...)
> revision IDs problematic for xmtn. It would probably be desirable to
> generalize revision IDs to make them more compatible with monotone,
> but I don't think this is a pressing problem.
True.
Well, last-revision is still usefull for N=1.
About previous-revision, the problem is that to view the diff
introduced by a revision, some back-ends force you to write
$ DVC -r direct-ancestor..revision
or such thing. So, what DVC does, when you press "=" on a revision in
a revision list buffer is that it shows the diff between the revision
you're on and its ancestor.
In git, (previous-revision X) is just X^.
>> And once more, "depending on the back-end", "diff" might not show
>> changes in metadata (permissions, symlink change, ...). So, there are
>> cases where "status" contains informations that "diff" does not.
>
> If one of the backend revision control systems happens to provide a
> command called "status" that is needed to show changes in metadata, we
> shouldn't dilute DVC's notion of status to accommodate this backend
> ("the status command might be useful to prepare your commit, or maybe
> its primary use is showing changes in metadata; it depends on your
> backend"). We should rather have the backend's implementation of diff
> also run the command called "status" and integrate its output, or add
> a special "show changes in metadata" command to this backend.
You should just keep one thing in mind about the philosophy of DVC: we
shouldn't hide the back-end, but instead, make it more conveinient to
use.
For example, there's still a M-x tla-changes RET command, which
actually does what the other back-ends would call "diff" (yes, the
author of GNU Arch liked to have commands doing the same as the
others, with a different name ;-) ). So, for example, the command
calling "baz status" shouldn't be called
M-x baz-diff-with-metadata-against RET. Still, the DVC version of it
can be M-x dvc-metadata-changes RET.
(about that: DVC is two things. An infrastructure to write an
integration of a version control in Emacs, _and_ a genericity layer
allowing one to type M-x dvc-whatever RET, and having DVC choose the
backend).
Anyway, just go ahead:
1) Your vision is valid
2) In the back-end supporting it, status against is not _very_ usefull
3) the IIRC, only GNU Arch supports it, and it shouldn't be our
priority.
--
Matthieu
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
