Matthieu Moy <[EMAIL PROTECTED]> writes: > Stephen Leake <[EMAIL PROTECTED]> writes: > >>> That's not a really interesting thing to do: what you want here is to >>> find all buffers of type TYPE, for a given back-end, and for a given >>> tree root. >> >> Yes, except we don't know the back-end. dvc-buffer-current-active-dvc >> is not set in source buffers, so we have to ignore back-end while >> searching, and get the back-end from the log-edit buffer. > > The convention in DVC now is that the root is the first parent > directory being a local tree of a back-end registered in DVC. > > The back-end in use is chosen according to dvc-select-priority.
There is also dvc-temp-current-active-dvc, which is easier to use than dvc-select-priority: (let ((dvc-temp-current-active-dvc 'xmtn)) (dvc-status "/Gnu/dvc-fileinfo/")) (let ((dvc-temp-current-active-dvc 'bzr)) (dvc-status "/Gnu/dvc-fileinfo/")) If I am actively using two back-ends for the same workspace, it needs to be easy to tell DVC which one to use for any given operation. The current mechanisms are ok so far, but could be better. >> Consider this use case: >> >> [...] >> >> But this user just wants one mtn database containing everything, while >> keeping the bzr databases separate. > > is simply not managed. Well, I want it to be managed :). And you keep telling me that DVC should not limit the user! I currently keep the DVC code in both mtn (for internal distribution) and bzr (for DVC development). I don't have the nested tree at the moment, but it is a common practice, so it needs to be considered. > This problem is unrelated from the issue we're talking about. Two back-ends is part of the context for the way I use dvc-add-log-entry, so it is related. > If you want your above setup to be managed correctly, you need a > solution that works for dvc-file-diff, dvc-file-ediff, dvc-diff, > dvc-status, ... well, just about everything in DVC. Yes, that's true. There is a lot of work to do. > Yes, you can imagine solutions for this, like an interactive prompt. > But that's in NO WAY specific to dvc-log-edit. The whole DVC is built > like this. You're building a highly-partial, ad-hoc solution for your > problem. Suppose I have another setup, which needs another feature, > and I fix only dvc-diff, then someone else needs something else, and > implements it only for dvc-status. Imagine the resulting mess. That is the way DVC got to where it is. And Emacs in general. In a world with infinite resources, both would benefit from being redesigned from the ground up. But that's not the world we live in. I don't have a problem with this style of development. The point is to keep in mind the ultimate context, and try to come up with solutions that are more general, and refactor when they are discovered. > [ Appart from that, versionning nested trees as part of the containing > tree is wrong in 99% of the cases. The subproject should be managed as > a separate project, and if you want traceability of the project as a > whole, most VCS have features to manage subtrees correctly (forest > extension for Mercurial, submodules for git, I think bzr has something > for this too, ...). That is a religious argument; we can't win it. We just have to live with it. In any case, the subproject is not crucial for me; we can drop it from the context. We should state somewhere in DVC that we don't support nested trees. The user guide would be the best place; that really needs to be rewritten. Having two back-ends for one workspace is crucial. >> 2) Keep only those where default_directory is under >> the root >> >> this is more expensive; comparing partial paths. > > Not that much. You're dealing with tens of objects, not thousands of > them. Doing 10 prefix comparison is instantaneous on a normal > computer. Right. I'm guilty of premature optimization. >>>> (defun dvc-get-buffer (dvc type &optional path mode) >>>> "Get a buffer of type TYPE for the path PATH. >> >> I don't think this works if PATH is other than root; > > True. At the moment, we manage only whole-tree diff's and status, so > we never need to create a DVC buffer corresponding to something other > than the root of a tree. > >> I haven't checked. Currently, the code typically gets PATH and DVC >> by calling dvc-current-active-dvc, which does the wrong thing in the >> case above, unless dvc-buffer-current-active-dvc is set properly >> (which it isn't in source buffers). > > Then, fix it, but be warned that I'll strongly oppose any change that > just changes the behavior of one command, making it inconsistant with > the whole DVC. That's fair. I'm trying to aim for more consistency. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
