[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 05.04.07 11:08:43, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> On 05.04.07 09:58:28, Matthew Woehlke wrote:
>>>> Andreas Pakulat wrote:
>>>>> cleanup - fix inconsistencies with the local checkout
>>>> [snip]
>> 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?
> 
> I'm not sure. What cleanup does in the svn case is fix broken stuff in
> .svn: 
> andreas at morpheus:~>LANG=C svn help cleanup
> cleanup: Recursively clean up the working copy, removing locks, resuming
> unfinished operations, etc.

Well in perforce checkout info is all maintained server-side (yup, no 
local pristine copies)... I guess 'p4 sync -f' is closest. That 
basically clobbers your current checkout and gives you a fresh (but 
identical) checkout.

Oh, and did I mention that by default everything acts on the /entire 
client/, not just the working directory? I don't think that matters for 
this discussion, but maybe worth mentioning.

>>> 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?
>> [snip]
>> 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.
> 
> Yes, thats exactly what I was thinking, i.e. you can't just click on a
> file in the project which opens it and then edit it. You first have to
> execute some vcs-action to do that.

Hmm... ok, I guess it's similar. I don't know how aegis works, so... :-)

> As aegis needs something similar I think we should try to find a way to
> execute some vcs-action before opening a file in the editor...

No, this is totally unnecessary/wrong with perforce. Most opening files 
is "look, don't touch"; edit should be a separate action. Alternatively, 
if you could intercept trying to save a file, and if it is -w, /then/ 
pop up a dialog asking if you want to open it for edit, that would rock. 
But files should not be opened for edit when you open them.

>>>> 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.
> 
> I think we mean the same thing: Providing a IVersionControl which
> provides stuff like add/remove/copy/... but leave stuff thats only
> available in 1 or 2 specific VCS systems to a subclass of
> IVersionControl for that specific VCS.

Right, except where you say "things that all VCS we consider supportable 
have in common", I would change that to "...*most* VCS we consider 
supportable...". That way we enforce consistency across common actions 
even if there are exceptions that don't support a particular feature.

>>>> 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.
> 
> Well, it might be nice if you work on a project in kdevelop and decide:
> I just fixed the 100th bug in my .0 version, lets tag a new release to
> be able to do that from within kdevelop. [snip]

Well, it's just MHO but tagging to me is a more complicated action that 
you need to take more care in doing than something I think I personally 
would want to put directly in KDevelop. Also it isn't as "directly" in 
the work flow as editing, committing, and even renaming, it is more "off 
to the side". But that's just MHO.

>> 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).
> 
> It kdevplatform module, but yes thats what I meant. [snip]

Ok, like I said the point is just to make a stand-alone application and 
not a KDevelop plugin, i.e. I don't want to have to run KDevelop to run 
"FooVCS GUI Client". :-)

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