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

[Timothee Besset <ttimo idsoftware com>]

I'm trying to look at this from the point of view of other source control
systems, such as SVN and AlienBrain (which I both use) and SourceOffsite
(which I don't use anymore, but anyway):

- SVN has versioned file properties. You can edit keys and values
associated with any file or directory, with versioning support.

- AlienBrain and Source Offsite are oriented towards exclusive locking. Or
at least you have to checkout a file before it becomes writable. What
usually happens is that first time you try to save and IDE finds out it's
-w, it will prompt you to checkout the file. I'm not sure at which level
you want to deal with this.

- I don't see an entry point to configure the access to the repository.
Login, server URL, password and everything?

Once CVS is working, SVN should be very easy to add. It uses very similar
paradigms. I would probably add AlienBrain support, not sure anyone around
here uses that too? (NOTE: it's quite expensive, and it's crappy, don't go
there)

It would be interesting to get the advice of someone using source control
like BitKeeper, Aegis, or Arch. Those are quite different to work with
than CVS afaik.

TTimo

On 09 Sep 2003 10:42:21 +0200
Jeroen Zwartepoorte <jeroen xs4all nl> wrote:

> 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.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Anjuta-devel mailing list
> Anjuta-devel lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/anjuta-devel
>