From kwrite-devel Tue Jan 04 10:02:17 2022 From: Kevin Funk Date: Tue, 04 Jan 2022 10:02:17 +0000 To: kwrite-devel Subject: Re: source code management refactor Message-Id: <2705669.7n5lTh1SPX () kerberos> X-MARC-Message: https://marc.info/?l=kwrite-devel&m=164129044830301 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1780720.iX17KnC6vl" --nextPart1780720.iX17KnC6vl Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" From: Kevin Funk To: kwrite-devel@kde.org Cc: "Christoph Cullmann (cullmann.io)" Subject: Re: source code management refactor Date: Tue, 04 Jan 2022 11:02:17 +0100 Message-ID: <2705669.7n5lTh1SPX@kerberos> In-Reply-To: References: On Tuesday, 4 January 2022 10:41:36 CET Christoph Cullmann (cullmann.io) wrote: > On 2022-01-04 01:04, Javier Guerra Giraldez wrote: > > Hi, > > > > I've recently pushed a small patch to add minimal Fossil support to > > Kate's Project plugin. It felt so good to contribute to my favourite > > KDE application after many (many!) years of using it! > > > > The next step, of course, is to get more Fossil functionality; ideally > > getting it to parity with the current Git support. > > > > Looking at the code, I found several places like "if git, do this > > very-git thing", which of course, doesn't scale to multiple SCM > > backends. I'm not a fan of gratuitous inheritance, but it seems the > > best way forward. As a nice bonus, it should make it easier to add > > similar features to Mercurial, and maybe Subversion. > > > > Now, I haven't done any real C++ since Qt3 days, so I'd like to ask > > for some comments before going too far into a bad design. > > > > I've just pushed a new branch: > > https://invent.kde.org/javier/kate/-/tree/work/javier/fossil_branches > > It adds a `scm/` directory with a base class and a class for each SCM > > supported. So far the features: > > > > - SCM detection (all SCMs) > > - get managed files (all SCMs) > > - get SCM icon (for Git and Fossil) > > - get current branch name (Git and Fossil) > > - list of branches (Git and Fossil) > > - checkout branch (Git and Fossil) > > - new branch (Git and Fossil) > > > > have been moved to use these new classes. > > > > Is this list the appropriate place to discuss design? or would it be > > better to open a PR and do it there (even if the code is still very > > much in process) > > Hi, > > first, cool that you want to help out ;=) > > Now, for the concrete feature: > > We started to implement Git without any abstraction as this seemed for > us to be the 90% user > base target for some SCM people will use and therefore some abstraction > seemed to be not that > needed on first glance. > > If one can handle more SCMs with a very lightweight abstraction that > doesn't hinder further > feature development and might increase maintainability, one could think > about such a thing. Hey, Just some food for thought: There's a VCS abstraction inside kdevelop, too, which is (iirc) pretty KDevelop agnostic and could easily be put into a separate library. Inside kdevelop.git: - kdevplatform/vcs for the interfaces - plugins/{bazaar, git, subversion, perforce, ...} for the implementations It even provides generic widgets (diff views and the like) on top of the abstract interfaces (see e.g. [1]). I always thought this could easily end up as some KF5 framework handling generic VCS management, actually. I won't able to work on it, but it'd be sad (to me at least) to see to VCS abstractions being maintained right next to each other. We know how "start with a lightweight abstraction" might end up a few years down the road :) Just FYI. Cheers, Kevin [1] https://dot.kde.org/2010/10/26/kdevelop-41-brings-git-integration > Given @waqar did most of the current Git work, I think he needs to be > the one deciding if > we want that. > > We discussed so far such things more on GitLab, given you already worked > on it in a branch, > one could even just open a merge request and discuss it there, then one > can even see > what e.g. ATM such an abstraction would imply. > > Greetings > Christoph > > > thanks! -- Kevin Funk | kfunk@kde.org | http://kfunk.org --nextPart1780720.iX17KnC6vl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQQ2TvpfY5VykH05KZnGTPVrE8rOXQUCYdQbKQAKCRDGTPVrE8rO XX8RAJ9Kn4ctYL6XLs5PPNzXHbj/mTZOnwCgkOxKub8v+zXYqnpRIFZW1+GrW9Q= =xIU3 -----END PGP SIGNATURE----- --nextPart1780720.iX17KnC6vl--