VCS Interface classes

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 30.04.07 11:05:09, Matthew Woehlke wrote:
>> dukju ahn wrote:
>> (Which brings up a good question, should we also have 'QString 
>> repoUrl(KUrl localPath)'?)
> 
> Hmm, I guess yes. It may be a convenient thing to have. Also that way we
> can avoid the isVersionControlled, because for that to know you only
> have to check the QString, it will be empty.

D'oh, that's an awesome point I didn't think of... I like it!

> Yes, especially since I hope we provide a repository browser.

Hmm, ok I assume that will be a new interface? You also need a 
listFiles() for a browser. :-)

>>> Detailed options will be specified by each VCS plugin itself.
>>> For example, some plugin will invoke option dialog box and have the
>>> user specify it.
>> ...except that the version parameters are QString's (which makes even 
>> more sense now that I think about it, because perforce also accepts 
>> dates as a means of specifying a version).
> 
> See the API dox, I already defined what exactly is allowed as revision:
> QDate-parseable date
> number
> HEAD/BASE

Missed that, thanks for pointing it out again. Um... problem, though, 
perforce needs to accept a file revision separate from a repo revision. 
IMO the list should be:

- QDate-parseable date
- number, with a file/repo specifier*
- one of "HEAD", "BASE", "WORKING", "HAVE"
- Any plugin-specific string?

(* A couple ways to do this... the perforce way would say 'use "#" for 
file, "@" for repo', although I would prefer 'r' for repo, or only use 
the prefix for one of them. In svn, they are of course the same.)

"HEAD" means the latest repo version. "HAVE" is a shortcut for "the 
version I have checked out" (which is NOT "WORKING"!)... or is that what 
"BASE" means? "WORKING" means to use the local copy. The difference 
between "HAVE" and "WORKING" is that "HAVE" refers to the file as if you 
reverted it first.

Perforce also allows specifying versions by labels or by the last 
version checked out by a particular client spec. This last one would be 
like saying "the last version annma checked out from her working copy in 
/usr/local/src/kde/my-branch/kdeartwork" (this sort of thing is 
server-side in perforce). I'm not sure why you would use it against 
someone else's client :-), but it does provide an obscure way to find 
out what the latest version you have checked out is, ala 'svn info'. (I 
was worried that this was impossible without some very ugly hacks akin 
to getting the repo version of a directory based on the working copy. 
Note: getting the repo version of a directory /in the repo/ is trivial. 
Come to think of it, doesn't svn actually have to jump through the same 
hoops?)

>> What's wrong with specifying 
>> the version like '52,107' to see revisions between r52 and r107?
> 
> Hmm, how about using a class "Revision" which can be either one or two
> revision strings (each can be one of the three above)? 

Unless the class is defined by the VCS plug-in with a standard 
interface, what would be the benefit of not adding to the list "any pair 
of the above, seperated by <well-known-separator>"?

-- 
Matthew
If you believe you received this e-mail in error, you are probably sadly 
mistaken, but if not, aren't you lucky?