Re: source code management refactor

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 | [email protected] | http://kfunk.org

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQ2TvpfY5VykH05KZnGTPVrE8rOXQUCYdQbKQAKCRDGTPVrE8rO
XX8RAJ9Kn4ctYL6XLs5PPNzXHbj/mTZOnwCgkOxKub8v+zXYqnpRIFZW1+GrW9Q=
=xIU3
-----END PGP SIGNATURE-----