source code management refactor

[Christoph Cullmann (cullmann.io)]

On 2022-01-04 11:02, Kevin Funk wrote:
> 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 
> :)

The issue with that implementation is, the interface itself might still 
be
not that kdevplatform dependent, but as far as I see the plugins 
themselves
use a lot of the kdevplatform infrastructure.

I don't see how that could be easily shared without a lot of work.
Besides even the Git plugin seems to have only minimal maintenance
over the last X years.

I would like to share code with KDevelop to avoid duplication,
but I somehow don't see how that would be easily feasible given
the lack of manpower in both projects and the lack of interfaces
Kate has and the different concept KDevelop has, e.g. just on singleton 
main
window.

Unfortunately, as we still had the proper chance to unify all that,
there was no con sense to do so :P I think we failed due to the fact
Kate::MDI didn't support overlapping dock widgets or something like 
that.

Greetings
Christoph

> 
> 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!

-- 
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org