Stephen Leake <[EMAIL PROTECTED]> writes:
> 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.
Sure, like any other modern VCS I know (git, hg, bzr, even GNU Arch
and svn). "X", in my example, was a revision, not a file.
> One thing I expected to find in DVC was more support for this notion.
That's definitely one of the goal. And that's why I thing the old
Emacs VC-mode doesn't really help to support modern VCS, because it's
too much file oriented.
> 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.
Well, in this case, you have to do several commits, so what's wrong
with
while (changes) {
M-x dvc-status RET
(select files to commit)
'c'
(edit log)
C-c C-c
}
?
> 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.
That's also an argument to have partial revert/reapply tools.
bzr has a "shelve" plugin to allow that. If you have multiple
unrelated changes to commit, you revert all but the one you want, then
probably test your project, commit, reapply some changes you shelved
earlier, test, commit, ...
I believe hg's mqueue does something similar, but I don't know it well
enough.
Darcs prompts interactively for each patch hunk at commit time. But
that doesn't really satisfy me, since it encourrage you to commit your
project in a state that never actually existed on disk (there's also a
feature to test your partial changes before commiting).
In DVC, there's nothing for that purpose up to now.
> 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.
In any case, you'll have to do multiple commits, and test your project
before you commit. If you're not too strict, "test" can mean just
"check whether it compiles", but it's sooooo easy to change foo.h to
add a function, bar.c to use it, and then to commit only bar.c
(remember, the CVS old good time, hey!)
> Again, committing more often mitigates this issue; maybe I'll just get
> used to doing that. We'll see.
Clearly. Commit are cheap, and relatively fast (depending on your
back-end. For example, git was designed so that any common operation
including commit would take less than 1 second on the linux kernel
tree).
> 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.
What most of them have is a feature to view the history, filtered by a
file or a set of files.
For example,
$ bzr log file.c
will show you the subset of
$ bzr log
touching file "file.c". But that's mostly a user-interface thing, the
model behind is still atomic commits.
> 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.
Yes, but the big difference is that it's commonly admited that
writting stuff in assembly language is inefficient and useless
compared to writting it in C with a good compiler.
I don't think DVC will ever provide _all_ the features of the
underlying system. Both because DVC is not mature enough, and because
DVC is more generic.
GCC can easily provide the greatest subset of all the back-ends,
because all the back-ends are turing equivalent, so, the greatest
superset is still a turing machine.
DVC can show you a similar interface, but can not _unify_ back-ends
with so different underlying model. Take the file-ID thing above:
that's a non-problem for git, who has a totally different model to
manage renames. The user will know one day or another what back-end is
used.
If you really want the _same_ interface, the solution is not an
additional layer, it's a bidirectional gateway. Tailor is one of them
( http://www.darcs.net/DarcsWiki/Tailor ), you also have foreign
branches for subversion and git in bzr, git-svn to contribute to SVN
repository using git, ...
And there's also an user-friendlyness issue here, but that's perhaps
more a personal opinion: I'm using Emacs because I like the way Emacs
teaches me unix. In Emacs, I don't have
M-x debug-without-showing-me-the-debugger RET, I have M-x gdb RET, and
I get something with all the power of gdb and the interface of Emacs.
I don't have M-x search-in-multiple-files RET, I have M-x grep-find RET,
and I can even type myself the find | xargs grep command there.
The day I don't have Emacs, or the day I want to migrate away from it,
I can still use what Emacs taught me.
> 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.
True.
> To me, that genericity layer looks like a consistent common front-end
> to several backends. But maybe that's just my vision.
The main reason for its existance it to have a single menu and set of
keybindings for all back-ends.
For example, I can type C-x V L in any tree, I'll get the log. But the
log will be formated in a "tla" fashion if I'm within a tla tree, and
in a bzr fashion if I'm in a bzr tree.
What's hardcoded in my fingers works regardless of the back-end, but
Emacs doesn't hide it from me.
--
Matthieu
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
