VCS Interface classes

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 30.04.07 12:24:48, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> On 30.04.07 11:05:09, Matthew Woehlke wrote:
>>>>> 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*
> 
> Hmm, this is another argument for a specific Revision class.
> 
>> - one of "HEAD", "BASE", "WORKING", "HAVE"
>> - Any plugin-specific string?
>>
>> "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?
> 
> ok, svn book helped here. BASE == the version of a file in the working
> copy without any local modifications. 
> 
>> "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.
> 
> Then HAVE==BASE.

Agreed, I thought it might.

> svn has two more keywords which might make sense to add:
> 
> COMMITTED and PREV, I'm not completely understanding when COMMITTED <
> BASE but PREV is always COMMITTED-1. And with those you can do this:
> 
> svn diff -r PREV:COMMITTED foo.c
> 
> and see the changes that the last commit did to foo.c.

The book says: "The most recent revision prior to, or equal to, BASE, in 
which an item changed." IOW, as per previous e-mail, I don't think we 
should support svn's "BASE", and should treat "BASE" as svn's 
"COMMITTED". I think what it's saying is if I check out r57 and the last 
change to foo.c was made by r42, then BASE(foo.c) is 57 and 
COMMITTED(foo.c) is 42. Note that for passing to diff, BASE==COMMITTED 
by definition of COMMITTED, it is really itemRevision()* where this matters.

(* note: I'm suggesting this change from latestRevision(); if I 
understood correctly, calling this on a local file gives the BASE 
revision not the HEAD revision, therefore I think 'latest' is misleading.)

But I would love for *all* plug-ins to support PREV, whether or not the 
VCS does (if it doesn't, it basically falls to the back end to 
translate). It's a major convenience. :-)

> Also in svn the 3 keywords BASE, PREV and COMMITTED only work on local
> paths. But I think this can be hidden in the plugin.

Right. I would guess "BASE" on a repo path means "the version you have 
checked out" if a: possible to determine that and b: you have the file 
checked out (it's easy in perforce, svn needs to know where the local 
copy of the checkout is), and "HEAD" otherwise?

>> 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?)
> 
> Not 100% following here, but IMHO that means we should have something
> like this:
> 
> class Revision
> {
> 	enum RevisionType {
> 		Number,

Does this consider that IIRC a cvs version "number" is e.g. "1.2.15"?

> 		Date,
> 		Range,
> 		Keyword,
> 		Branch, 
> 		Tag,
> 		PluginSpecific
> 		}
> }
> 
> Where in the case of Range it would have two "childs" each having a type
> != Range. That way its more clear to API users what a Revision QString
> contains. Else they have to read and remember the api dox. As far as
> methods go I think we'd have setValue(QVariant) and value(). The
> QVariant allows to carry a QPair, int, QString or QDate. 
> 
> Or don't we need Branch/Tag as Revision kind of Parameter? I think for
> CVS thats needed, for SVN branch/tag would mean another repo location,
> how is it with perforce?

I'm not sure how branch works with svn, I guess it is the revision of 
the file in e.g. /trunk when the branch was done? In perforce, a label 
is e.g. "foo_label", i.e. just a string identifier.

Short reply: I'm not convinced this doesn't fall into PluginSpecific. :-)

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