VCS Interface classes

[Andreas Pakulat]

On 01.05.07 12:40:09, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> >I've updated the interfaces to reflect the stuff that was discussed
> >until now.
> 
> To clarify: isVersionControlled does not distinguish between "no" and "an error 
> occurred", or...?

No it doesn't.

> Would it be possible to change the returns from int to something that more 
> clearly indicates that the value is a task ID? A typedef would be fine, 
> although I can see using some form of class so that you could query e.g. the 
> result, status, etc, from the task object (i.e. more like a job). Hmm, that 
> would mean wait() would become a member of the task, I guess.

Hmm, I'm starting to think we should have a VCSJob here, subclassed from
KJob (which is already the case in svn plugin - AFAIK).

> Should localRevision() have a default for the second argument? (I'm not sure if 
> this needs to be in the interface?) If this is to be synchronous (should it 
> be?), Revision needs a way to specify that an error occurred.

Invalid Revision should do for that, no?

> import() and checkout() are not async? (Just checking if that is 
> intentional...)

No thats just oversight.

> Thinking more about RevisionType, I don't think the current system works. I 
> think we need to say that plug-ins will subclass Revision and provide an 
> overload of RevisionType to add their own values.

Then we should use QFlag(s), those can be extended. However how does a
user of the vcs plugin get to know that? Right, it doesn't. Users of
our VCS interface only have the interface. 

Of course we could just revert Revision to be a plain wrapper of either
a QString or a pair of QStrings (for defining a range) and then just
document that all plugins should allow a revision number (with or
without dots), a date or a keyword like BASE and HEAD. Anything else is
plugin specific, although code doesn't really have a way to find out
which plugin it talks to at the moment.

Another option would be to completely remove the Revision argument from
the interface and let the plugin always ask the user via a customized
dialog for this. And actually I think this might be more sane than to
try to find something common about revisions.

Then diff() would only take a source and destination to prefill that
dialog, for example.

Ok, well I'll comment on the diffs.

> +    // Make async, take a list again... the list is probably more efficient, esp.
> +    // for server-side VCS's like perforce

That was async already, the list will make the semantics a bit more
complicated: If run on a dir with recursive == off, will it return a map
with 1 entry for the dir or will it return a map with all dirs/files in
that dir, or both?

> --- ibrowsingversioncontrol.h.orig	2007-05-01 12:33:54.281144234 -0500
> +++ ibrowsingversioncontrol.h	2007-05-01 12:33:26.000000000 -0500

Hmm, yeah splitting that makes sense.

> @@ -39,17 +39,19 @@
> -        Number,
> +        GlobalNumber    /**<Global repository version when file was last changed./*/,
> +        FileNumber      /**<File version number, may be the same as GlobalNumber.*/,

I added these two for now

> +        // Remove Keyword, Branch, Tag... not portable
> +        // Remove PluginSpecific, plug-ins will define a superset of this list
> +        // if type is none of the above, that means plugin specific

As I said above currently users don't know which plugin and thus which
values in this enum are available.

Andreas

-- 
You feel a whole lot more like you do now than you did when you used to.