[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 05.04.07 09:58:28, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > cleanup - fix inconsistencies with the local checkout
> 
> Hmm... since I have never used anything like this, I can't tell you. 
> What would this do?

Well, for svn I had to use this a couple of times, specifically when
interrupting a commit while it transfers data. There were some other
occassions but I can't remember exactly what they were. This is
something that is user-initiated if the vcs says: "Hey, somehow I
screwed my "working-copy", please fix me".

> > Do other VCS systems need other actions? Is there stuff that cannot be
> > mapped to other VCS systems?
> 
> Perforce has a good bit of stuff that needs to be added in addition to 
> the generic list. For instance with p4 you manage changelists, you have 
> a 'default' one but you can also move files to other changelists that 
> can have their descriptions set in advance. This makes it easy to work 
> on multiple change sets because you don't have to tell the VCS what 
> files you do or do not want to check in so often. Also it is an 'edit' 
> based system, i.e. you have to 'open for edit' files that you want to 
> change.

Sounds a bit like aegis which Kuba uses... So if you have a number of
files in your changelist you can't just edit them? You have to do this
via a p4 command?

> Maybe you should add an interface for all "common" actions (like 
> property editing) but allow VCS plugins to specify which ones they 
> support, and hide the others. In that case I would add to the list 
> property editing and opening a file for edit.

You can subclass interfaces to add more specific methods. So the general
one should provide only those things that all VCS we consider
supportable have in common (at least to a certain extent).

> What about support for tagging, do you think KDevelop needs to provide 
> interfaces for that? (I would say "no", it's an administrative action, 
> and I think those are probably better done at the command line or by a 
> dedicated front-end. For KDevelop I would say focus on what you do with 
> files as part of the development process.)

Well, this is largely different between CVS and SVN already - AFAIK -
which means: No. The various VCS plugins may choose to provide this via
context menu actions, but I don't see the need for this in the
vcs-iface.

> Overall I do think having a sort of 'standard interface' is a good idea, 
> I would definitely plan to share anything we can between cvs/svn/p4 and 
> maybe others (like they can have a shared diff viewer, shared 
> interactive merge tool, etc). Also, p4v has a history tree that shows 
> branches, integrations, etc. I think svn has the same concepts, so this 
> might be a cool shared widget.

Yeap, especially the history-"network" is something I'd like to see,
instead of just a list of revision-author-comment entities.

> However I am also thinking that it would be ideal to put all of this
> in a lib in a way that would allow it all to be used by other
> applications, for example a stand-alone dedicated vcs application that
> would use the same back-ends would rock

Well, if we use standard widgets for parts of this, we're going to
provide a libkdevplatformvcs. So a possible VCS-only app could start on
top of kdevplatform, however I don't think anybody here wants to start a
new kdevcs-lib project unless you do :)

> Obviously I assume all the diff/merge UI stuff will be in libraries so
> that you still have the stand-alone Kompare. There should however be
> an interface for that to allow displaying the vcs path instead of a
> temporary file name when diffing within the repo (or local vs. the
> repo).

I'm currently hoping we can either integrate KDiff3 or use its code to
provide the diff/merge. IMHO KDiff3 works pretty well and provides
already the possibility to view the diff between two files and integrate
the changes into a third one.

Andreas

-- 
Stay the curse.