Skip to content

Draft: Add branch handling to Fossil-based projects

Javier Guerra requested to merge javier/kate:work/javier/fossil_branches into master

Local refactor (within the project plugin) to decouple UI from the choice of Source Code manager.

Design so far:

  • Add a .scm field to KateProject, pointer to abstract class BaseSCM.
  • Concrete subclasses for each SCM: Git, Subversion, Mercurial and Fossil. Each of those hold a .basedir field, but that's an implementation detail. It's conceivable some could use a URL instead, for example.
  • Detecting the type of project (among those allowed by config) creates an instance of the appropriate class.
  • The list of files and of branches are methods on the SCM object, as are the branch create and check-in/-out.
  • Removed the .m_branchChangedWatcher field from KateProjectView. Instead, there's a changedCommit signal, each SCM subclass might implement it differently.

Implementation State

Detecting and file listing are implemented on all SCMs (moving the existing code). Branch handling is implemented on Git and Fossil (Git is a thin wrapper on GitUtils functions, Fossil implements those in the class itself (they're quite simple)).

Requests for comments:

  1. Naming! I've chosen "SCM" as the generic term and not VCS because I think it could also include "non-versioning managers" like FTP server, dropbox lookalikes, or even plain directories. But that smells of architecture astronaut. I haven't made any attempt to handle .kateproject files within this architecture.

  2. Where to hold the pointer. Right now it's a field of the KateProject, and I think it's the semantically appropriate way. But there are some functions that take the base directory and call GitUtils functions, without any reference to the project object. I was tempted to either:

    1. add some global basedir->scm map (ugly) or,
    2. make some methods static so they could be called with just the basedir. But they would have to rediscover the repository type and maybe create a temporary SCM object.

    So I settled on adding a project arg to some function so they can get hold of the scm object.

  3. Some types defined in gitutils.h (like Branch or CheckoutResult) are appropriate for the SCM methods. I considered moving them to either basescm.h or a standalone header, but decided to leave such a change for later. The benefit would be that the UI files wouldn't #include GitUtils, since the appropriate SCM implementation encapsulates such concerns.

  4. Some methods in the Git class are very thin, since they just call the corresponding GitUtils function. Nothing wrong with that, but just moving the code there might be easier to read (or maybe not?). Like the previous one, I decided to not to do that yet, to minimize changes. If later on that makes it look too different from the others, It would be an easy change.

TODO:

  • GitWidget panel. The only UI changes could be the icon and label in the tab. All the other functionality could preserve the same UI with just different implementation.
  • GitHistory option. Fossil has very good web UI for that, so it could just be hidden in non-Git projects.
  • Diff display. Could be reproduced as is, or leave to the external UI (one of the strengths of Fossil).

Merge request reports