source code management refactor

[Javier Guerra Giraldez]

Thanks all for your comments,  I'll open the PR (or merge request?)
and carry on the conversation there, especially about some design
issues that I'd like some comments on.

Quickly answering some of the comments:

- I fully agree that git support covers (at least!) 90% of developers
out there.  It's just that Fossil makes me so much happier while
developing... and yes, most of the concepts easily translate between
both, so (almost) the same UI works great.

- I haven't read the KDevelop code, but I will.  Although I personally
find the Kate one more usable.

thanks again!

On Wed, 5 Jan 2022 at 09:23, Waqar Ahmed <waqar.17a at gmail.com> wrote:
>
> Hi,
>
> Thanks for working on this. I checked the code and so far looks okay to me.
>
> When I wrote the first version of git plugin, we discussed it a bit
> and wanted it to be very basic and no one really thought about other
> potential SCMs that could plug-in as well and as such _everything_ is
> very git-centric. Some of the discussion is availble in the repo I
> think, and there is probably an open issue for git integeration as
> well which no one has closed yet.
>
> For the abstraction idea in general, I am no scm expert so I am not
> sure if it will scale well to all the SCMs out there. But this is
> about fossil, so I'd say lets not worry about others for now. The
> abstraction would make sense to me if the features that fossil
> provides are very similar to git so that we can easily map them into
> existing widgets.
>
> Regarding discussion, there are no limitations, you can just create a
> PR or issue and we can discuss there and perhaps others can chime in
> too.
>
> On Tue, Jan 4, 2022 at 5:05 AM Javier Guerra Giraldez
> <javier at guerrag.com> 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)
> >
> > thanks!
> >
> > --
> > Javier



-- 
Javier