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

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


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


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

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

> p.s. I'm CC'ing the devtools list as well.
I get the same mail 4 time ;-). Yes I think it of interest for 
devtools, too. Thanks.

Regards,
Johannes