REMINDER: Final review of VCS interfaces

[Andreas Pakulat]

On 23.05.07 03:51:47, dukju ahn wrote:
> 2007/5/22, Matthew Woehlke <mw_triad at users.sourceforge.net>:
> > The VCS interfaces are looking good, and we would like to start moving
> > over to them next week (5/28). If you have not already, please review
> > them and comment if you see any problems, things that look wrong, things
> > you don't understand, things that might not work with your favorite VCS,
> > etc.
> 
> 1.
> >from the comment on IBasicVC--
> "revisions can contain a date in format parseable by QDate"
> Why don't we use QDateTime instead of just QDate?
> It can handle time information also.

Right, the docs should be adjusted. We should probably also note there
that if parts are missing QDate's defaults are used.

> 2.
> Why do we return VcsJob as a value? Should it be a pointer?

Correct, needs a change.

> 3.
> virtual VcsJob IBasicVcs::status( const KUrl::List& localLocations,
>                      RecursionMode recursion ) = 0;
> 
> Is this an ASync method or blocking method? I guess it would be blocking
> because it fetches information from local-locations.
> Then we need IBrowsableVcs::status( QString, RecursionMode ) also. And
> it should be non-blocking. Its associated signals should be defined too.

None of the methods in the interfaces are blocking. All they should do
is create an instance of a proper VcsJob subclass which can do the
actual job and return a pointer for that instance. Then the caller
connects to the VcsJobs signals and afterwards starts the job. At that
point the job starts to execute - _always_ in a separate thread or
process, i.e. non-blocking. Now if the caller needs the result before he
can go on he can wait for the VcsJob by calling VcsJob->wait() and
afterwards retrieve the results via the API.

> 4.
> In case of svn, there is "svn info" It displays useful informations belows.
> Why don't we add showInfo() on both IBasic and IBrowsable and
> display information dialog box?

Because that doesn't work for other VCS systems and the most valuable
information in the output already has API, that is the revision, the
repository location and the last-changed-date

Of course subversion could provide its own ISubversion interface with
this function.

> 5.
> This is my question. Who would be the user of these interfaces?
> Good guests would be repository browser, status displayer.

Yes, also user-definable scripts come to mind and things like
the refactoring-plugin, even the teamwork plugin could use this (update
the local working copy if a team member committed something important).

> BTW, if the user invokes context-menu somewhere, who will
> reimplement IPlugin::requestContextMenuActions()? Will there any
> VcsManager or controller that manages every loaded VCS plugins and
> creates action for ctxmenu? Or ctx-menu is left for each plugins?

Each VCS plugin should do this on its own, of course checking wether the
file that is under the project or editor context is a versioned file.

Andreas

-- 
There was a phone call for you.