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

[Jeroen Zwartepoorte <jeroen xs4all nl>]

Hi,

On Tue, 2003-09-09 at 12:41, Johannes Schmid wrote:
> Hi!
> 
> > 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.
> 
> They are signals in the moment (sorry that I confused you) but of 
> course if it is better to have callbacks and we can use these.
> 
> > - 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.
> 
> See was Naba has written here. I think given the possiblity to get a 
> signal it the message is NULL is the best.
> 
> > - 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.
> 
> Do we really need that? If someone wants to commit multiple files he 
> maybe wants to commit the whole project.

I really think we need to support this. I frequently apply a patch from
somebody while working on other stuff. In that case, i only want to
commit ChangeLog and the file that was patched. I don't want cvs to
commit any of my other (unfinished) changes.

> > - 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.
> 
> I thought about this. But log_project or status_project does not sound 
> very nice IMHO.

See Naba's mail about dropping the separate project/file methods.

> > - Does file_update really need a branch parameter? Don't have you to
> > specify a branch when you checkout a module?
> 
> Yes the Nabas mail.
> 
> > - I assume file_status is supposed to return something? The current
> > method is void (returns nothing). Same applies to file_diff and
> > file_log.
> 
> Not really. I assume that we have to use command line tools to access 
> the VCS. They will just return a stream with the file log/status/diff.

Is this really the same across different VCS systems? I could imagine a
newer VCS system to return an XML representation of the log/status/diff
instead of plain text like what cvs returns.

> > - 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?
> 
> I have not worried about GUI. What should this callback parameter look 
> like? What should the recipient display?

There are a couple of virtual methods that need to be added for things
like:

- VCS Properties: returns a GtkWidget pointer which has widgets to
configure the VCS properties (for cvs, this would basically be CVSROOT).

- Commit dialog: have the backend return a dialog from which the user
can select how to commit the files (the compression property (-z3) in
cvs comes to mind).

- Update dialog: have the backend return a dialog from which the user
can select how he/she wants to update the files (branching, -d option
for directories, -P option to prune empty directories etc. for cvs).

What i meant about this callback is this: presumably, a commit/update
dialog would only need to be shown once the user has called update() or
commit() on the GnomeVCS object. So the backend would tell the frontend
to display the dialog using a callback: the backend has no idea
where/how to display a dialog (the frontend might even be a console
application that uses curses or whatever). So the backend would call the
frontend's callback. Then the frontend would get the "commit widget"
from GnomeVCS and display that.

> > 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?
> 
> I looked at cvc, arch and SVN if it would be able to have a common 
> interface. I haven't looked at any others.
> 
> > Overall, this is a good first step. Keep it up!
> 
> Well, today was my first school day in the graduation class has started 
> and I do not know how much time I will have to work on anjuta/gnome-vcs 
> but hopefully I will have some.

Heh, same problem here with work :)

One thing i forgot to mention is this: shouldn't we have a join()
virtual method in GnomeVCS? Or is this specific to cvs?

Regards,

Jeroen