VCS Interface classes

[Andreas Pakulat]

On 30.04.07 11:05:09, Matthew Woehlke wrote:
> dukju ahn wrote:
> > 2007/4/29, Andreas Pakulat <apaku at gmx.de>:
> >> Hi,
> >>
> >> * diff and log parameters, am not 100% sure there
> > 
> > virtual void log( const KUrl& localOrRepoLocation,
> >               const QString& revision ) = 0;
> > 
> > 1.
> > How can the caller know repository location for the given local file?
> > i.e. suppose there is /home/kdev/kdevelop/main.cpp.
> > The caller doesn't know whether it is
> > 
> > svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop/.... or
> > https://svn.kde.org/home/kde/trunk/KDE/blah
> 
> ...I thought that the point was for the plug-in to figure that out? 
> (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.

> In fact, since there is e.g. 'svn cat' and 'p4 print', I see no 
> particular reason why at least diff() couldn't operate on a file that is 
> not under VCS control. (log() in such instances should just fail with 
> e.g. ERR_NOT_IN_VCS.)

Agreed, and I'm going to post a new set of interfaces later today, where
repo-stuff and local-stuff is separated into two interfaces.

> > 2.
> > Subversion accepts start revision and end revision.
> > 
> > Solution is Just specify the local URL only and,
> 
> That won't work, what if I want to diff something that I don't have a 
> local copy of? (True, this likely arises in KDevelop only if we provide 
> a version of 'diff' that allows entering paths, but remember I wanted to 
> see these interfaces useful in a VCS front-end as well.)

Yes, especially since I hope we provide a repository 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

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

Andreas

-- 
Live in a world of your own, but always welcome visitors.