[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andras Mantia wrote:
> On Thursday 12 April 2007, Matthew Woehlke wrote:
>> Andras Mantia wrote:
>>> On Thursday 05 April 2007, Andreas Pakulat wrote:
>>> My general feeling is that not all of the actions below need to be
>>> in the interface. [snip]
>>> So those actions that are called only via the GUI by the user
>>> should not have to be in the interface, they cam be provided by the
>>> VCS plugin themselves.
>> Except this limits the ability to write scripts (or at least
>> plug-ins) that can use arbitrary VCS back-ends. However the plan to
>> use interfaces handles this, we have optional interfaces that need
>> not be implemented, but provide consistent API's when available.
> 
> I think this is the most important point where we disagree. To write a 
> VCS plugin you don't need any interface there. I can write a subversion 
> plugin without inheriting from any VCS interface and still provide all 
> the functionality the user needs. The interface might make sense in two 
> cases:
> 1) a third party plugin wants to do some VCS operation

I guess writing a generic VCS UI would fall into this category? This is 
something else I would like KDevelop to help support. With the Grand 
Unified Interface we're currently discussing, you can write a 
fully-featured, backend-agnostic VCS UI.

> 2) you make a script to do more VCS operations in automatic ways

3) to provide consistency of interface
4) to enable sharing of translations

> In both cases (but mostly in case 2) most of the time you want to just 
> run operations which doesn't need further user input. 
> add/remove/checkout is something like this. Resolving conflicts, 
> looking at commit logs is usually not. They can be done from the main 
> menu, the context menu or from the toolbar with actions provided by the 
> VCS plugin. 

Why should I not be able to write a script that says 'do this merge, pop 
up the UI for anything that needs to be resolved, then commit it'?

>>>> commit - let the VCS transfer local changes into the VCS
>>>> update - fetch latest changes from VCS into local dir
>>> This is normal to have, but IIRC ClearCase needs a lock before
>>> changing the file, so maybe automatically lock before commit and
>>> unlock after it (and remove th lock/unlock actions)?
>> lock/unlock are already going into a separate interface. Anyway,
>> perforce is the same except the lock is done for you (probably svn is
>> the same too, just less noisy). 
> 
> I doubt svn locks anything. Another user can commit in the same file 
> easily while you are working on it. All you get is a conflict (and an 
> error message on commit).

svn does atomic commits, therefore it has to support transactions. That 
means either locking, or ability to roll back partial transactions. Note 
that I'm talking about a lock that only lasts from when you hit enter 
after 'svn ci' until svn is done running, i.e. a few minutes at most in 
extreme cases. Perforce I /know/ works this way.

>> The way to handle this is to have the 
>> ClearCase back-end do the lock/unlock if that is required to do a
>> commit; this qualifies as an Implementation Detail, which we are only
>> concerned about when they dictate interface requirements.
> 
> Actually it is only true if you want a dirty implementation, because 
> IIRC in ClearCase you locked the file before editing and unlocked after 
> the commit, but well, doesn't really matter here.

Ah, well you could do that too. Can you edit a non-locked file? If not, 
this is similar to perforce (if you think of edits as being an advisory 
lock), I guess this "lock" is a strict lock though? Would it suffice if 
the edit action (which should ALWAYS be invoked before editing a file - 
it is a no-op on svn of course) did a lock and a commit did an unlock?

>>>> log - Show a complete history for a given local resource or VCS
>>> I don't see why we need this in the interface, it should be enough
>>> to have in the GUI.
>> I guess the objective is to not need a separate GUI 99% of the time.
> 
> Separate GUI? It will be provided by the plugin.

I think one objective of having a defined interface is to provide the 
GUI as part of the interface, so that you don't *need* to re-implement 
the GUI for every back-end.

>> Anyway since the ideal is to be able to write an abstract GUI using
>> these interfaces, we still need it in the interface. :-)
> 
> Do we want such a GUI? I mean, will the plugins only do backend stuff 
> and not plug their actions into the user interface and instead we have 
> another plugin for the GUI? It doesn't really make sense because of the 
> differences between the VCS variants.

Why not? :-) One thing I get from this is that different VCS's /aren't/ 
that different, or at least can be easily made to seem similar enough 
that you can do exactly this.

>>>> resource diff - show a difference between local file and latest
>>>> VCS version, or 2 VCS versions
>>> I don't really see a use case for this.
>> You've *never* done a diff? I do them all the time (like right before
>> commits, especially). This so astounds me that I am certain there
>> must be a miscommunication.
> 
> Doing the diff is usually an operation from the GUI. When would you do a 
> diff from a 3rd plugin or a script?

We're not talking about only scripts, we're also talking about KDevelop. 
Why should I not be able to click on a file I am working on and say 'how 
is my working copy different from the latest repo copy?'. Would you 
prefer to have to leave KDevelop and go to some other application (or a 
command line) to do this?

>>>> copy - copy a file with VCS methods (history is kept)
>>> You cannot copy with history in CVS...
>>>
>>>> move - move/rename a file with VCS methods (history is kept)
>>> Same here. I have the feeling that this copy/move shouldn't be in
>>> the interface.
>> Not even via merge()? That's too bad, but IMO these should still have
>> an interface (otherwise you *can't do them*, at least not without
>> leaving KDevelop, and that would be unfortunate). They just won't
>> preserve history on CVS.
> 
> That sentence would have pissed off the KDE developers during the CVS 
> era. ;)

Which, that it's too bad it's so hard to preserve history on CVS? It's 
just stating a fact. ;-)

>> I personally consider these to be core operations on par with add()
>> that scripts should be able to rely on using.
> 
> I agree this is important operation, even useful in scripts as well, 
> just that it needs a warning (from the VCS plugin) that it might not 
> preserve the history.

Ok, that's fine, I don't see why copy() can't produces a warning. :-)

>>>> resolve - mark a conflicted file as resolved
>>> Belongs to the VCS plugin only.
>> I disagree, for the usual reason (no leaving KDevelop). 
> 
> And as I said, you will not leave KDevelop, you just wouldn't be able to 
> mark a file as resolved from code (3rd partly plugin or script).
> We can have this action provided by the plugin *in the GUI*.

Ok, I think I can clarify. The point of an interface is to:
- Improve consistency by...
   - Standardizing the presentation of VCS actions
   - Allow sharing translations (which makes translators lives easier)
   - Using common GUI's
- Allow scripts to use VCS methods

...and this is why log(), globalVersion(), diff(), etc are all things we 
want in the interface. That way we have *one* GUI using the standardized 
interface instead of every single back-end reinventing the wheel when it 
comes to UI's that are common to most/all VCS's.

Code reuse = good.

>> We never really talked about this, but I don't think there should be
>> an interface for "special". Individual back-ends can provide (outside
>> the defined common interfaces) anything they feel useful. 
> 
> And how would you access them?

The same way you want plugins to provide diff, etc; the back-end adds 
any additional actions not defined by one of the interfaces it 
implements. They are only scriptable if you write the script for that 
specific back-end, and only if said back-end provides them in a 
script-friendly form. Which is OK.

>>> Regarding the need of an "edit" action before actual edit, this
>>> could be done the following way: the framework could have a
>>> signal "documentAboutToOpen" to which the VCS plugin listens and do
>>> what is needed to allow the editing.
>> Nothing needs to be done on open AFAIK. However I think we need the
>> edit interface because scripts probably won't open the file in the
>> editor part in order to manipulate it. :-) And this means we should
>> have 'unedit'.
> 
> Cannot this be the same as lock/unlock?

It isn't in perforce. Maybe it is in ClearCase (see questions above)?

>>> Similar signal could be
>>> an "aboutToSave" or "documentSaved" which can be used to create
>>> scripts that automatically commit your changes on save.
>> Huh? I do *NOT* want my changes committed when I save the file
>> locally! That's not the way it usually works.
> 
> My next sentence was : "This is weird, but might make sense." I don't 
> want to make it default, but if someone wants this behavior, could 
> assign a script doing the commit to this event.

Ok :-).

>  There was also the idea to perform the "edit" when saving a file.

Yes, I'd already mentioned that also (and made the RFE for an onSave 
event to kwrite-devel)

>> Hmm, be sure to add your weight to the discussion going on in
>> kwrite-devel on this topic, then (you can CC here, I've been doing so
>> on some of the posts but most respondents aren't). I didn't mention
>> an onOpen signal as I didn't know of a need for one.
> 
> This has little to do with kwrite-devel (and KTextEditor). The framework 
> *knows* when a file is opened, right? Possibly knows also when it is 
> closed or saved. It is the KDevelop platform which needs to emit the 
> signals at the correct time.

Hmm... ok, you're right about open AFAIK. You are overloading the 'save' 
provided by KTE? (Does that work? It catches also ctrl-s, for example?) 
I'm not sure if that is preferable to having KTE emit a signal or not, 
the latter sure seems to be safer. (aegis also needs to do a 'save as' 
instead of a 'save', so I guess Quanta is not alone...)

-- 
Matthew
GDRLaH - Grin, Duck, and Run Like a Hippo! :-)