VCS Interface classes

[Andreas Pakulat]

On 30.04.07 14:10:36, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > What should unedit() do? I mean, revert() reverses to repository
> > version, commit() checks in the local version into repository. What else
> > is needed?
> 
> unedit() clears the effect of edit() iff* diff(BASE,WORKING) is empty, 
> i.e. the file has been marked for edit but does not actually differ from 
> the repo copy.

Agreed.

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

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

> I think we should return something more like a pid to use in the
> signal. In fact, that should work, because then all methods can be
> made async() and we can add a wait() method. I'm not sure how the
> scripting will work but it seems that it will be more common for
> scripts to want to be synchronous because I would think they usually
> rely on the previous command to complete before they can issue the
> next. I'm not necessarily saying we should change anything, just
> something to keep in mind.

Agreed.

> > I'd like to see
> > mostly all things in an async way. Eric4 just gained the possibility to
> > have async commit() and that way you can initiate a commit() and then go
> > back to the IDE and look at the diff of your local changes to write a
> > proper commit message. Which IMO rocks. Not even Eclipse has this, IIRC.
> 
> Isn't that just a matter of the pending commit() not blocking the rest 
> of the interface, and the dialog being non-modal?

Yeap, but to have that the commit() method needs to be async.

> Does that make sense?

I snipped it, because I agree with your above proposal about async+wait.

> >>> * usage of simple QString's for any parameter that can be a repository
> >>>   url (anything that is always a local url should stay KUrl), if a VCS
> >>>   system can't use a url for describing a repository location
> >> ...if diff() takes a repo location shouldn't the parameter be QString? 
> > 
> > Thats something I wasn't sure about, so I made my first write-up easier
> > by sticking to KUrl everywhere ;) The thing is I don't know wether the
> > "targeted" vcs systems (i.e. the ones we were talking about here) really
> > work with a url scheme. If not repo location needs to turn into a
> > QString and then we really need 2 different interfaces.
> 
> Is 'svn+ssh://path/to/somewhere' a valid KUrl? (I guess if '+' is 
> allowed in a protocol name and the protocol doesn't need to be known.) 

Yes I think it is.

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

Andreas

-- 
Don't relax!  It's only your tension that's holding you together.