[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

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

Ok, well in perforce there is 'sync -f' which says 'unconditionally 
download everything in the workspace' (I forget, it may even clobber 
opened files also). Maybe that is similar?

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

Um, I'm not sure I follow you. You "can't"* edit a file unless you open 
it for edit. Once it is open, you can move it around your open 
changelists. An open changelist basically just serves to keep track of 
different things you are working on at once, mainly you can pre-enter 
the description and you commit single changelists, so this makes it easy 
to commit some files but not others.

(* you can chmod +w a file yourself, but perforce won't know you are 
editing it unless told, so it will never be committed. This can be a 
"feature", or a PITA :-).)

The main practical impact here is that before you can hack on a file you 
have to "open" it (vcs'd files are usually -w until you open them). 
Changelist management I think is unique enough that it can be left to 
the front end to worry about.

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

The reason I suggested it was to provide naming consistency for actions 
that are common but not universal. Otherwise two back ends might wind up 
with different names for equivalent actions.

>> What about support for tagging [snip]
> 
> 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.

Agreed. IMO KDevelop front ends should not support it at all, I think 
it's a task more suited to a stand-alone vcs client.

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

I think this became a question of 'where does it live'. I don't see any 
reason a generic VCS client can't depend on kdevplatform (assuming I am 
remembering correctly that this means it depends on the kdevelop module, 
not the kdevelop application).

-- 
Matthew
<insert bad pun... on second thought, better not>