Re: [Anjuta-devel] Gnome-VCS API discussion

[Jeroen Zwartepoorte <jeroen xs4all nl>]

Hi Johannes,

On Mon, 2003-09-08 at 15:21, Johannes Schmid wrote:
> Hi!
> 
> I have put my first proposal of a Gnome-VCS API on http://www.anjuta.
> org/jhs/gnome-vcs . Please comment on it. Anything is welcome. Of 
> course the code will go to a CVS repositry sometime later.

Here are some comments after looking at the source files:

- Are the callbacks you have defined as part of the GnomeVCSClass
_really_ callbacks or are they signals? I'm asking because callbacks
shouldn't be part of the Class. Callbacks should be defined separately
and then added/registered to an object (see the GbfBuildCallback in
gbf-project.h). After looking at the implementation i see that they're
signals. You shouldn't use signals for these kinds of things. They have
quite a large overhead. It's better to use a callback for stdout &
stderr output.

- Strings in callbacks/signal handlers should always be "const". You
don't want the recipient to have to free those.

- Do the file methods really need a message parameter? For CVS these
operations don't affect the repository. You only need to provide a
message once you commit the changes.

- For file_commit, you want to be able to commit multiple files at once.
So the const gchar *file parameter shouldn't either be a double pointer
or a GList (i prefer the last one). This also applies to file_update.

- A better naming scheme is to put the operation first, and then whether
it applies to a project, file or files. So
s/project_commit/commit_project, s/file_add/add_file.

- Does file_update really need a branch parameter? Don't have you to
specify a branch when you checkout a module?

- I assume file_status is supposed to return something? The current
method is void (returns nothing). Same applies to file_diff and
file_log.

- Instead of having const gchar *message parameters in almost all
methods (do VCS system other than CVS really require them?), wouldn't it
be better to have the recipient register a callback that tells it when
the VCS backend requires a message? The recipient can then popup a
dialog asking for a message from the user.

- I'm missing some GUI virtual methods. For example to configure a
GnomeVCS project. Also, things like a commit and update dialog might be
useful (since every VCS system has its different quirks). The backend
should provide these GUI elements, but the recipient should display
them. Perhaps you can have a callback parameter as part of the commit &
update methods that gets callback with a GtkWidget that the recipient
can display?

Has anyone ever done a basic comparison between various VCS systems to
determine which things they have in common? How can we add/show VCS
specific commands to an IDE?

Overall, this is a good first step. Keep it up!

Regards,

Jeroen

p.s. I'm CC'ing the devtools list as well.