Stephen Leake <[EMAIL PROTECTED]> writes:
> If we are declaring DVC support for tla dead, that simplifies the fix.
> It also simplifies cleaning up the texinfo manual; we can simply start
> over.
It's not necessarily so simple. When we switched from Xtla to DVC, I
initially wrote the bzr back-end, and Stefan was writting the hg one.
Instead of just "starting over", I took pieces of code from the tla
support, made them generic, trying not to break the tla support, and
using the newly made generic code in bzr. Keeping the tla support was
as much a helper than a constraint: you know that your code is generic
when it supports two back-ends, and when you have existing support for
one back-end, it's easier to write just one other at a time.
I wrote a few emails on this list with metrics on the number of lines
of code. The conclusion was that the switch from Xtla to DVC was
mostly about moving and generic-izing code from Xtla to DVC's core,
and then, new back-ends can be written in a few hundreds of lines of
code.
> Do we still want to support arch, but by some other dvc back-end?
I'm not the best guy to answer this question: I have very limited time
to spend on DVC, (and I spend most of it trolling on the mailing
list ;-)). I'd like to keep the tla/baz back-end, but I'm not going to
actually spend much time on it unfortunately.
(note: GNU Emacs still uses primarily CVS, and some people use tla,
which AFAIK is the only distributed VCS which is part of the GNU
project, so the Emacs core developers have a non-technical motivation
to use GNU Arch)
> Well, we can simply not run "git status -v"; that is the answer for
> the current definition of dvc-status and dvc-diff.
Not the current definition. In the definition you propose, it's not
possible, but with the current unification of diff-mode and
status-mode, it is possible.
Indeed, I've just implemented it, the patch is below and really
straightforward (it can probably be improved a lot. At the moment, the
output of git-status is still in the ewoc footer, and redundant with
the ewoc itself).
In command-line, I almost never use "git status -v", because the
output is too long, but from DVC, I really think this is the best
place to commit from. You have all the information needed about the
working tree, plus the complete diff, and all that in an Emacs buffer
with the usual facilities to navigate in it, plus things like "j" to
switch between a file diff and status line.
> Actually, monotone has the same thing, called the "workspace
> manifest".
Ah, I didn't know it. Indeed, monotone is one of the only modern VCS I
didn't try (yet?). Since git is initially somehow an efficient rewrite
of monotone, that's not so surprising.
> I think the git index/montone workspace manifest fit in category 1);
> they extend the information that can be displayed in the status
> buffer. In fact, that is mostly what motivated my rewrite of the
> status ewoc; the old one did not allow displaying all of the
> information. I just didn't know enough to say so clearly at the time
> :)
It's not just about the information displayed. In git, for example,
git-diff shows you the diff between the working tree and the index,
"git-diff --cached" shows the diff between the HEAD and the index, and
"git-diff HEAD" shows you the diff between the working tree and the
HEAD. To show that to the user, you need 3 commands, they will have to
appear in the UI.
Indeed, you really have two different flows depending on whether you
intend to use "git-commit" (commit the content of the index) or
"git-commit -a" (commit the content of the working tree, as other VCS
would do).
> Or extend "diff table of contents" to really mean "status summary", as
> I thought it did initially. Which would probably lead to not having a
> separate dvc-status-mode.
That's what I still think.
> That's not the _only_ distinction currently; dvc-status invokes a
> separate backend function than dvc-diff, resulting in different
> information being displayed.
It's not the only distinction for the functions dvc-status and
dvc-diff, but it's the only one for the mode.
I obviously agree that we need several functions to run the back-end
tool differently and to fill-in the buffer and the ewoc differently,
but I still don't see how you can have two modes without loss of
functionality.
--
Matthieu
=== modified file 'lisp/xgit.el'
--- lisp/xgit.el 2007-07-09 18:56:47 +0000
+++ lisp/xgit.el 2007-07-16 12:04:38 +0000
@@ -175,7 +175,7 @@
(dolist (elem (xgit-parse-status-sort (nreverse status-list)))
(ewoc-enter-last dvc-diff-cookie elem))))))))
-(defun xgit-status (&optional against path)
+(defun xgit-status (&optional against path verbose)
"Run git status."
(interactive (list nil default-directory))
(let* ((dir (or path default-directory))
@@ -188,7 +188,7 @@
(setq dvc-buffer-refresh-function 'xgit-status)
(dvc-save-some-buffers root)
(dvc-run-dvc-sync
- 'xgit '("status")
+ 'xgit `("status" ,(when verbose "-v"))
:finished
(dvc-capturing-lambda (output error status arguments)
(with-current-buffer (capture buffer)
@@ -208,6 +208,10 @@
"No changes in %s"
(capture root))))))))
+(defun xgit-status-verbose (&optional against path)
+ (interactive (list nil default-directory))
+ (xgit-status against path t))
+
(defcustom git-log-max-count -1
"Number of logs to print. Specify negative value for all logs.
Limiting this to low number will shorten time for log retrieval
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
