[RFC] Workingstyle of different VCS systems

[Matt Rogers]

On Apr 5, 2007, at 10:31 AM, Andreas Pakulat wrote:

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

IMHO, the svn support should handle this automatically rather than  
providing an explicit action for it, and doesn't really belong in the  
VCS interface.

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

On a side note, can we please start calling it SCM (for Source Code  
Management) rather than VCS? We're not writing KDevelop to handle  
various versions of things, we're writing it to manage source code.
--
Matt