[RFC] Workingstyle of different VCS systems

[Andras Mantia]

Hi,

On Thursday 12 April 2007, Matthew Woehlke wrote:
> Andras Mantia wrote:
> > On Thursday 05 April 2007, Andreas Pakulat wrote:
> > [snip]
> > 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
2) you make a script to do more VCS operations in automatic ways

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. 

> > > state - get the state of a local file, currently possible state 
flags
> > Maybe useful from a script, I don't see what you could do with this
> > in a plugin's code.
>
> You don't use file tree, do you? :-) The state information is
> presented visibly in the file tree so you can see at a glance what
> files are in what state.

Files tree where? In KDevelop4 surely not, as I don't use it. In 
KDevelop3 I disabled the subversion support some time ago due to its 
bugs. But what you say makes sense, so it can remain.

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

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

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

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

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

> >> repositoryVersion - gives the latest version in the repository
> >> localVersion - gives the version of the local file
> >
> > Use case?
>
> Same as e.g. 'svn info', usually because the user "just wants to
> know". I feel it is a sufficiently standard action that it should be
> included.

Same here. If you just want to know (see), use the GUI to get the 
information.

> >> merge - merges differences between 2 sources into the local file
> >
> > Merge is usually a complex operation which might require manual
> > solving of conflicts, further committing and such. Do we really
> > need to expose it to scripts/code?
>
> Yes, because otherwise you have to leave KDevelop to do a merge. One
> objective is to avoid having to use external tools for common
> operations. (Note that resolve() is also in the interface.)
>
> ...but I've never heard of a merge requiring "further commits",
> usually the merge is something you do to generate changes withing the
> working copy, *then* you commit. Otherwise you are talking about
> non-atomic commits (ok, cvs is like this AFAIK) which are IMO broken.
> :-) Anyway, I don't see the problem.

Again, what script would do a merge? Isn't it something you do yourself 
as a user, when you want? This is exactly what you described, steps 
done by the user.
If you would use merge from the script, it would mean merge, resolve 
conflicts and commit. But I don't see any reason why this needs to be 
done from an external script.

> Yes and no, 'sync -f' means forcibly re-checkout *everything*, so it
> is a combination of revert everything and also check out anything you
> might have been missing, accidentally deleted, etc.

This would be "svn revert" followed by an "svn up". 

> >> 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. ;) People often did copy/move files around and were warned after 
that this loses history (which is not so nice in many cases). AFAIK the 
only solution in CVS to preserver history on copy/move is to manually 
do this move on the server.

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

> >> info - Show some info of the local checkout
> >
> > I think this is GUI only stuff.
>
> Same comment as log.

And same comment from me. ;) And I'm not convinced until I see a use 
case for it.

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

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

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

> > 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.
 There was also the idea to perform the "edit" when saving a file.

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

Andras



-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070412/6443eba3/attachment.sig>