VCS Interface classes

[Andreas Pakulat]

On 30.04.07 12:24:48, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 30.04.07 11:05:09, Matthew Woehlke wrote:
> > 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. :-)

Uhm, yes. Thats the IRepositoryVersionControl interface, which will have
some methods that are also in IBasicVersionControl, but work directly on
repo locatons (like add, move, copy, log, diff, ....)

> >>> 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.

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.

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.

> 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,
		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?

> >> 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>"?

See above, its clearer to the API user and we don't have to start
thinking about a regex that correctly parses the string. Plus we can
have some type checking with QVariant.

Andreas

-- 
Your present plans will be successful.