Christian Ohler <[EMAIL PROTECTED]> writes: >> The purpose of xmtn-revision-get-file-revision seems to be (it doesn't >> have a doc string) > > The theory behind not having a docstring for this function is that it > only implements an interface specified in DVC-API; the only thing the > docstring might say is "xmtn's implementation of > `revision-get-file-revision'", but this is implicitly understood > anyway, since every function whose name has the prefix "xmtn-dvc-" is > an implementation of the respective DVC API function. So there's > nothing to document. Only deviations from or extensions of the > generic contract should be documented.
Ok, that makes sense. > In practice, however, the specification of this interface is missing > in DVC-API, and the function name prefix is just "xmtn-" instead of > "xmtn-dvc-", since DVC looks for the function under this wrong name > due to an apparent typo in the DVC core. These are bugs. Ok. I'll try to notice and fix them when I run across them. >> to get the contents of a particular file revision >> into a buffer, and also into a file. Sometimes that file is a temp >> file (as in the diff case), sometimes a user-requested file (when >> retrieving an old revision for other reasons). > > It always puts the file contents into a buffer, never into a file. I guess you mean the _intent_ is to put the contents into a buffer; in fact the implementation uses a temp file. There should also be a function whose purpose is to retrieve a previous revision of a source file, and stores it in a user-accessible file with a reasonable name; that is useful when you are trying to find a bug introduced by a change. Although I guess the user can simply save the buffer after using xmtn-revision-get-file-revision. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
