VCS Interface classes

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 30.04.07 14:10:36, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> Please feel free to present an interface for that. It shouldn't be part
>>> of our basic - all vcs plugins have to do this - interface, IMHO.
>> I'll need to think about it for a bit. :-) Perforce almost has to have 
>> this. For VCS's that don't support it, it should be possible to write a 
>> generic version that uses the local file system to provide this 
>> functionality.
> 
> I'd rather have this an optional interface, so perforce would have it
> but svn doesn't.

I'd love for svn to have it also :-) ...but I agreed on making it 
optional, sorry for not making that more clear.

>> Yes, you need some sort of 'what do you support' function. IIRC we had 
>> originally talked about using flags for the mapping instead of 'bool 
>> recursive'; you would then ask for supported flags. This would be most 
>> extensible in case some VCS supports other things as well as, or instead 
>> of, exclusions.
> 
> Agreed. I was a bit lazy when writing the interfaces and didn't re-read
> the whole thread ;)

Hehe, I'm thinking I really should re-read the thread also, but... ;-)

>> Perforce repo paths, however, look like '//path/to/somewhere'. Of course 
>> if you needed to do something silly like use 'p4://path/to/somewhere' in 
>> all external code, I don't see a problem with that, the back end can 
>> just strip the protocol.
> 
> Well, I don't like the idea of introducing arbitrary protocols here, I'd
> rather have a QVariant and thus be able to use KUrl or QString, for
> repository locations. That seems to be much cleaner.

That's fine, I was just brainstorming how we could bludgeon perforce 
repo paths into something KUrl would accept if we felt it important.

(Is 'svn' really any less of an 'arbitrary protocol' than 'p4' would be? 
:-) The only obvious difference that comes to mind is that the perforce 
protocol is proprietary and unpublished.)

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