Christian Ohler <[EMAIL PROTECTED]> writes: > Matthieu Moy, 2007-07-05: > >> Stephen Leake <[EMAIL PROTECTED]> writes: >> >>> In diff-mode buffers, the key "i" is bound to 'dvc-pop-to-inventory', >>> which is (currently) only defined in tla. >>> >>> What is "inventory", in tla? I wonder if it has an analog in the other >>> backends. >> >> This would be >> >> bzr ls -V >> git ls-files -t >> hg status --all >> >> That is: show all files in the working tree, and say what is the >> status of each (versionned, ignored, unknown, ...). > > So, if the status buffer had a switch to toggle between showing all > files and just the "interesting" files, we would no longer need a > separate inventory mode.
Exactly. The `tla-inventory-mode' is here just because we didn't realize that we actually needed a file-list-mode instead (which "status" is, indeed). >>> I would rather use "i" for 'ignore', which is an commonly used >>> operation common to all backends. >> >> Good idea. And you need much more often to ignore a file than you need >> to see the inventory (usually, "status" is what you want, it shows you >> only the files you need). > > I'm surprised to hear that 'ignore' is used so frequently that we need > a single letter for it. I usually only modify .mtn-ignore a few times > after setting up a new project to add patterns for files generated > during build, and only rarely have to adapt it after that. I don't use "ignore" _very_ frequently, but since I use "inventory" even less ;-). Indeed, it depends on your usage of a VCS. I usually work alone on most of my projects, so I sometimes add files one-by-one to my ignore list instead of defining good paterns, just because "no one will see", and I also often create new archives, because I often work on very small "projects" (I'm so used to version control that I often type "$VCS init" right after any "mkdir" ;-) ). Still, there are also real-life _and_ "clean" cases where I have to use ignore frequently : projects which generate a lot of files, and which generate them within the working tree. I have this on a shared project with teachers, generating a lots of PDFs from LaTeX, and since we also have a lot of relevant .pdf files, I don't want to ignore *.pdf all at once. > The commands `dvc-ignore-file-extensions' and `dvc-ignore-files' are > probably used with similar frequency, so they should be available with > roughly the same number of keystrokes. > > xmtn's implementation of both of these functions will ask between two > and three questions: > (1) Ignore %s? > (2) Save buffer .mtn-ignore? If the .mtn-ignore had no unsaved changes before the operation, I don't see any case where you would answer "yes". > (3) Add file .mtn-ignore to workspace manifest? Indeed, since the file will show up next time you run "status", I'm not sure asking the question is relevant at all. > So even if we use a single letter for 'ignore', the entire operation > will currently still require 3-4 keystrokes in xmtn. Typically, > question (3) will be asked only once; and I guess we could silently > save .mtn-ignore without asking (2) unless the user already had > .mtn-ignore open and modified. Oops, I anwsered exactly this above before realizing it was what you were saying ;-). > (By the way, when told to ignore a directory, xmtn also causes all > (current and future) files inside the directory to be ignored. How do > other backends implement this? I'm not sure I understood the question: for all the VCS I know, "ignore a directory" means never go into it, and therefore, the content is obviously ignored. Indeed, several VCS (hg, git) just ignore the notion of directory. A directory exists when there are files in it (but they get troubles to manage directory renamings). > Maybe there should be a third ignore operation: ignore directory > without contents? I can't find any real use cases for this off the > top of my head, though.) So, if I understand the question correctly, my answer would be "nobody does it this way, and no, there is no use case for it" ;-). -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
