Matthieu Moy <[EMAIL PROTECTED]> writes:
> 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^.
Hmm. In monotone, there is no such thing as "a revision of a file";
each "revision" is a set of changes to a set of files; it may just be
one file, it may be more.
Comming from a CVS background, I initially found this frustrating, but
it's growing on me. There is a web-based viewer that offers a list of
all the revisions that affect one file ("monoview", I think). It would
be interesting to see how that works.
One thing I expected to find in DVC was more support for this notion.
For example, when preparing to commit changes, I would like to see the
possibility of assigning changes to different files to different
revisions, and collecting comments on each revision separately. That's
how I work; I edit whatever file seems to need editing, even though
"logically" the edits are for different purposes. Being able to define
what revision each change is part of would make that clearer.
Until I hit a file that has two independent changes that belong in
separate revisions, I suppose. That's an argument for committing more
often. Which is easier when it doesn't require a (slow) network
connection.
I can approximate this now by marking the files involved in one
revision, committing that, then marking another set, etc. That
requires several passes thru the status buffer display, which is
inefficient; I'd prefer to think about each file only once, in the
order they happen to be displayed.
Again, committing more often mitigates this issue; maybe I'll just get
used to doing that. We'll see.
(Hmm. Maybe drag'n'drop (or just cut-and-paste) in the status buffer
display, to group files according to revision, would be a nice
interface)
If other backends still directly support (or require) the notion of
"revision history of one file", it will be a major conflict for the
DVC front-end.
> 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.
I agree with this goal in general.
However, one way to make things more convenient is to provide a
consistent front-end.
For example, the primary reason I'm using DVC is because I want to use
monotone, and DVC seems like a good front-end for monotone.
DVC happens to be maintained in bzr, and I want to improve DVC. So I
have to use bzr. I'd _prefer_ to not have to _learn_ bzr, since I
already know DVC (this is stretching reality, but that's the way I'd
like it to work :).
As an extreme analogy, consider the gcc C compiler. One C front-end,
many machine-code backends. No-one is _required_ to learn the machine
code or assembly language for a particular processor in order to use
it, but they can use assembly with C if they want to.
Obviously, C is far more mature than DVC, and the semantic
transformation between C and assembler is far more than we want to do
in DVC (although I've always wanted the "dwim" command; Do What I
Meant" :).
> 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.
Or perhaps there should not be a "DVC version of it", if this operation on
metadata is not provided by other backends, or not something the
"typical user" will need/want to do.
> (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).
To me, that genericity layer looks like a consistent common front-end
to several backends. But maybe that's just my vision.
Backends should feel free to define back-end specific Emacs functions,
without corresponding DVC versions, if appropriate.
The manual would need an addendum for each backend to document such
things.
--
-- Stephe
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
