Matthieu Moy <[EMAIL PROTECTED]> writes: > Stephen Leake <[EMAIL PROTECTED]> writes: > >> Part of my point is to move code out of the back-end into the >> front-end, where it is shared. Looking thru the back-ends for >> dvc-diff, and dvc-status, there is quite a bit of UI stuff that is >> common, and could easily be shared. > > Yes, it could be factored better. Note that there's indeed another > task probably more urgent, which is to remove any dependancy from DVC > to the tla back-end (they're here only for historical reasons).
Yes; it keeps bugging me that "loading tla" shows up in Emacs. It's on my list of things to fix. 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. Do we still want to support arch, but by some other dvc back-end? >>> I'm still not sure you'll really get any difference between the two >>> modes if you still allow commiting from the diff buffer (which I want >>> to have). That may be true. Part of the point of writing a new mode is a learning process, to fully understand everything it does. So if my new dvc-status mode does go away in the end, I'll try to write up the rationale for it in a DVC document somewhere, so the next guy doesn't have to go thru the same process :). >>> For example, which mode would you use for "git status -v"? >> >> The example you give has a summary at the top, and a standard gnu diff >> below. So I don't see how this is different from what bzr does. > > It's not "git diff", but really "git status -v". So, it's primarily a > "status" command (showing unknown files, for example), but it also has > a diff. Ok, that's clearer. > So, if you chose to treat unknown files in status-mode only, you can't > run "git status -v" in diff-mode, or you loose features. Indeed, if > you have any feature available in status-mode and not in diff-mode, > then you lose this feature if you run "git status -v" in diff-mode. > > It _is_ different from brz, and if you want bzr's back-end in DVC to > do that, you'd need to do "bzr status; bzr diff", roughly. > > Now, I'm asking the question again: which mode will you use for "git > status -v"? Well, we can simply not run "git status -v"; that is the answer for the current definition of dvc-status and dvc-diff. That would mean accepting the loss of this feature. Note that this is not really a "new" feature; just the combination of two existing features. It's more of a back-end optimization than a new feature. If the general discussion of "what should the DVC UI be for status" results in "a status buffer with an associated diff buffer", then the git implementation of dvc-status will be particularly simple. >> I don't have git installed at the moment (I could easily add it; there >> is a Cygwin package), and the online manual >> http://www.kernel.org/pub/software/scm/git/docs/git-status.html >> doesn't describe the output. So I can't speculate further. >> >> However, I think you've asked the question backwards; it should not be >> "what should DVC do with this backend feature", but "How do we get >> this backend to do what DVC wants". My goal (as I've said before :) is >> to have DVC provide a common UI to several back-ends. > > This is where I disagree. DVC shouldn't hide anything from the > back-ends. It has to hide _something_, or it won't be useable for multiple backends. > We've already discussed that here, BTW: > > http://article.gmane.org/gmane.emacs.dvc.devel/717/ Well, yes, we've discussed it. That doesn't mean it's settled :). The goal is to find a good compromise. >> On the gripping hand, if there is a good idea in there, we should >> consider using it in DVC, and getting the other backends to do it as >> well. > > Take git. > > git has something that no one else has: In addition to the repository > and the content of file on disk, you have something called the index, > or "staging area", which contains the to-be-committed content. > > So, for example: > > $ echo one > foo > $ git add foo > $ echo two > foo > $ git commit -m foo > > will still commit "one" as the content of "foo", because it's the > content you added to the index. Actually, monotone has the same thing, called the "workspace manifest". On commit, it becomes the revision manifest. "mtn automate inventory" shows a comparison of the workspace, the workspace manifest, and the base revision manifest; that's what xmtn-dvc-status displays in dvc-status (or will, when I finally finish it). > In DVC, you have two options to manage that correctly: > > * You can hide the index from the user. Then, the user will lose > several interesting git features. > > * You can show the index to the user. Then, you have no way to unify > this concept with any other back-end. (Except monotone.) Ok. So we are faced with the notion of an important concept that DVC aught to handle nicely that only one (or a couple) backends support. In general, there could be several answers: 1) if it fits as an exension of an existing UI, then extend it; the other backends simply won't use the extension. 2) add a new UI mode that does it nicely. 3) ignore it, and suggest users use the command line to access it. 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 :) >>> By trying to make a strong separation between diff and status, you'll >>> end up adding limitations because some commands will need different >>> features that are not in the intersection. >> >> I can't parse that. It is precisely _because_ there are commands that >> are not in the intersection that we need different modes for diff and >> status. > > +----diff-----+ > | | > +---+-status-+ | > | | | B | > | A | | | > | | | | > +---+--------+ | > +-------------+ > > What I mean is that whatever choice you make about what belongs to > diff, what belongs to status, you'll get a feature in the back-end > that needs (A and B on the diagram) two things which are in diff and > status, but that are not in the intersection. Then, chosing between > status-mode and diff-mode will mean losing features for both > choices. Hmm. I guess the distinction is between what DVC says belongs to status and diff, vs what the backend says about that. "git status -v" is a concrete example; it provides both the "status summary" (A) and the "full diff" (B). But the current DVC setup says those belong in different UI buffers. So the question is whether and how to make some nice feature available in DVC; that leads to the three choices above. In this particular case, providing a nice partnering between a dvc-status buffer and a dvc-diff buffer seems like the way to go. 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. >> I guess I'm not sure what you mean by "strong" here. > > I mean, the opposite of the current distinction, which is just in the > name of buffer. That's not the _only_ distinction currently; dvc-status invokes a separate backend function than dvc-diff, resulting in different information being displayed. In practice, there is significant overlap in the information in the two buffers; the most noticeable difference is the lack of "unknowns" in a diff display, and the lack of a "full diff" in the status display. The other, more important, difference is what commands are available, thru keys and menus. We have not settled that issue. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
