Stephen Leake <[EMAIL PROTECTED]> writes: > Do we have a use case where a back-end needs to override dvc-status > (or dvc-diff) _entirely_?
I don't have a particular use-case in mind. xmtn might be one, but I didn't look enough to tell. The way we manage nested for tla/baz could qualify as a use-case for that, but it would probably be better to extend it to other back-ends than making it a special-case of tla. I'm not opposed to have an implementation that doesn't provide directly a way to override dvc-status, as long as we have an easy way to provide it later, as needed. Fortunately, this is the case. I tried to explain in my previous message, more details follow. > No. I was suggesting two different organizations, in two different > VCS's. Well, your point was that dvc-add-log-entry could not know which log buffer to take in the case of nested trees. If you don't version nested files as part of the super-project, you don't have this problem. Good, we finally understand each other ;-). > But none of this was really important. Having the same file versionned by two different VCS is IMHO bad, but not bad enough to be really forbidden. It would probably be better to version it with one VCS, and use something like tailor to export it to another VCS. But use-cases like "I use X for actual versionning, and I abuse Y as a back-up system for my whole $HOME, because I don't trust X." is reasonable enough. > So DVC needs to support nested trees; it currently does not. Well, it "manages" nested trees in the sense that it behaves well in the presence of nested trees. One of the reasons why I didn't work on nested tree support for DVC (together with lack of time ;-) ) is that nested tree support for the back-ends we manage is still immature. For example, ifever a back-end adds a "--recursive" option to commands like diff and status, it really change the way we should deal with it. You probably didn't try what we did for Xtla, but it was actually quite good. When you ran "status" or "diff", it started a process to look for nested trees in the background. When the nested trees were found, it displayed a line "T? subtree/" for each nested tree, and started for each subtree. When the subtree process completed, the "T?" became either a "TM" or just "T " (that's from memory, I didn't try that for a long time). So, in one buffer, you could see whether you had uncommited changes the tree _and_ the nested trees. RET, or mouse click on the line corresponding to the nested tree poped the corresponding status buffer (already filled-in in the background). > I don't see how it could both allow (total) back-end re-implementation, > _and_ reduce duplicated code; they are conflicting goals. Roughly (incomplete, untested), (define-dvc-unified-command dvc-status ...) (defun dvc-dvc-status <whatever you'd have put in dvc-status>) (defun <very-specific-back-end>-dvc-status () code for the special case) Now, say, eg bzr is a normal back-end. dvc-status would call (apply 'bzr "dvc-status"), which wouldn't find a bzr-dvc-status, and therefore fall-back to dvc-dvc-status. And say, xfoo is a special back-end. dvc-status would call (apply 'xfoo "dvc-status"), which would find xfoo-dvc-status. But as I said, if you go for your solution, we can migrate to my solution later, if needed. So, there's not much difference (search google for yagni if you want an argument against my solution ;-) ). >> Allowing a back-end to override dvc-status is actually quite easy. the >> `dvc-function'/`dvc-apply' stuff already allow a default fallback >> implementation. > > Only if we _don't_ take the approach I'm advocating! > > This is the approach dvc-status takes now; it _requires_ duplicated > code, and allows different behaviors. Not "quite" the approach you're advocating, but almost so. > If the back-end has to provide _all_ of dvc-status (as required by > define-dvc-unified-command), then we have _not_ reduced duplicated code. > > If the back-end has to provide _all_ of dvc-status, then having common > behavior relies on updating duplicated code; that is already not > happening. In my proposal, the back-end _can_ provide all of dvc-status, but it doesn't _have_ to. Anyway, as I said, going for your solution is OK to me, since we can migrate to mine as needed without touching the back-ends. -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
