Stephen Leake <[EMAIL PROTECTED]> writes: >> 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.
Well, depending on the difinition of "where it is" ... At the moment, DVC is cool, but it's also very much inconsistant, different back-ends re-implement things that are managed by the core. See, for example : bzr is one of the back-ends having more features. That's the one we began with, and I've worked rather hard on it: $ wc -l bzr-*.el 82 bzr-core.el 121 bzr-dvc.el 204 bzr-revision.el 69 bzr-revlog.el 267 bzr-submit.el 743 total It's 743 lines of code because it's heavily relying on DVC. Almost anything I've added to the bzr back-end was thought to be generic enough to be applicable to other stuff. DVC's core is not totally generic, but it's ~10k lines of code, so, for bzr, <10% of the code is specific, and 90% is generic enough. So, yes, ad-hoc solutions are partly what makes free software evolve, grow, live, but a bit of code factoring, and generic solutions do not harm either ;-). -- Matthieu _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
