[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 12.04.07 16:43:43, Matthew Woehlke wrote:
> Andras Mantia wrote:
> > 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'?

And do this please on a couple of projects I have open!

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

Uhm, the length of the checkin depends on the amount of data you
checkin. I managed all the stuff for my thesis in SVN (pdf's, data,
latex, presentations and the visio files) and some commits took quite
some time, even on my DSL line. So it could as well be half an hour on
extreme cases or 2 hours on low-bandwidth network.

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

I'm not sure Clearcase needed a lock-when-editing, IIRC it worked pretty
much the same way svn works. I think adymo has some better Clearcase
knowledge, I hope he has time tomorrow to look into this enourmous
thread (IIRC its one of his short days at university).

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

Yeap, although we haven't touched distributed VCS like svk yet. (Is
darcs also a distributed vcs?)

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

Well, but this would be done through the context menu of the file and
the context menu is filled by the plugins.

> >>>> 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 already have the backends re-inventing the wheel. At least thats what
the last commits to cvs looked like, i.e. not using the outputview
anymore.

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

Sure, the application provides the actions, kpart just says where it
wants the actions to be shown in the menu (via XMLGUI). Same as
kdevplatform's actions will work. The application that uses KDevPlatform
will need to define in its .rc file which actions it wants to have.

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

For aegis we need to extend KTextEditor I think, because SaveAs asks the
user for the filename, we'd need a SaveAs that takes a KUrl.

Andreas

-- 
You will have a long and boring life.