Re: [Anjuta-devel] Gnome-VCS API discussion
- From: Naba Kumar <kh_naba gmx net>
- To: Jeroen Zwartepoorte <jeroen xs4all nl>
- Cc: Johannes Schmid <johannes schmid gmx de>, Anjuta Devel <anjuta-devel lists sourceforge net>, gnome-devtools gnome org
- Subject: Re: [Anjuta-devel] Gnome-VCS API discussion
- Date: 09 Sep 2003 15:23:48 +0530
On Tue, 2003-09-09 at 14:12, Jeroen Zwartepoorte 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.
Just curious. Did you mean callbacks == virtual functions?
> - 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.
>
CVS has the option to provide the message, but I don't know what is it
really useful for.
> - Does file_update really need a branch parameter? Don't have you to
> specify a branch when you checkout a module?
>
Yes, it does (although, rarely). When we want to switch branches in the
checked out version of the source, we do update with the given branch.
This makes sure our current modifications (if any) stay in the updated
version and to avoid doing fresh checkouts. Passing NULL, should of
course update the current branch.
> - 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 think the better approach is to have it passed to all the methods
requiring it (optioanlly or otherwise). If a NULL is passed during the
invocation of the methods, we can then emit a signal to retrieve the
message. Otherwise message passed is used.
This is because, we do not want to assume the messages will be always a
user feedback (although that's how it is in normal circumstances). The
commit should be donable by automated programs handling the CVS
operations. In such cases, if we rely on a signal for providing the
message, it will put unnecessary burden of maintaining the state of the
operation at the automated-program's end to make sure the currect
message is passed.
The signal emission can also prepare and pass the list of modified files
(just like command line CVS).
Also let us not complicate things with 'Projects' and 'Files' in
GnomeVCS. There is no projects in CVS (or other VCS implementations, I
suppose) and therefore there is no reason we should have it in GnomeVCS.
There are only files and directories. We don't even need to distinguish
between files and dirs also. Just have, for example, _commit() instead
of _commit_project() and _commit_files().
Regards,
-Naba
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]