[RFC] Workingstyle of different VCS systems

[Andras Mantia]

Hi,

 I'm trying to summarize my comments here instead of replying to 
separate mails.

On Thursday 05 April 2007, Andreas Pakulat wrote:
> Hi,
>
> before I propose an update on the VCS interface I'd like to get
> people's experience with VCS systems. I have myself good experience
> with CVS and SVN but those two are pretty similar. I also used
> ClearCase about 3 years ago but don't recall the exact details.

I'm in a similar situation, just that last time I used ClearCase 5 years 
ago.

My general feeling is that not all of the actions below need to be in 
the interface. As I understood this interface could be used by other 
(non-VCS) KDevelop plugins or external scripts to do version 
controlling operations without knowing what VCS system is used for the 
current project.
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. What should be in a VCS plugin is another question and 
maybe worths a discussion (do we want KDevelop to be a full VCS client, 
or it should provide just the basic actions and let other application 
to do more complex ones). Actually as I see part of discussion was 
about this part...


> So currently we're aiming for something like this:
>
> add - adds a resource to the VCS
> remove - removes a resource from the VCS
This is OK from me.

> checkout - fetch "something" from the VCS into a local dir
I doubt we need this in the menus, but makes sense to have in the 
interface when creating new projects (you might be able to create a new 
project directly from the repository).

> import - import a local dir into the VCS
If we do not map the interface 1:1 to the VCS commands, I suggest to 
merge this action with the "add" one. 

> state - get the state of a local file, currently possible state flags
> 	are:
> 	Added, Uptodate, Modified, Conflict (between VCS-version and
> 	local version), Sticky (some CVS thing, no idea what it means),
> 	NeedsPatch (what does that mean?), NeedsCheckout, Directory,
> 	Deleted, Replaced
Maybe useful from a script, I don't see what you could do with this in a 
plugin's code.

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

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

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

> annotate - ==svn-blame, AFAIK, i.e. show which line of a file was
>            modified by whom in which version
Same opinion as for "log".

> repositoryVersion - gives the latest version in the repository
> localVersion - gives the version of the local file
Use case?

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

> addignores - set information which files should be ignored by the VCS
Might make sense.

> revert - reverts local changes
> cleanup - fix inconsistencies with the local checkout

I saw a discussion about this. Cleanup in svn is something that I don't 
remember to see in CVS or ClearCase. The perforce's 'sync -f', isn't 
revert?
Cleanup is something that should be hidden IMO, and probably having an 
option to tell the plugins to "try to fix errors" and the Subversion 
plugin should automatically run cleanup if needed (and the flag is 
set).

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

> info - Show some info of the local checkout

I think this is GUI only stuff.

> mkdir - create a new directory in the local checkout and add it to
> the VCS
I suggest to use mkdir from KIO and add from the interface.

> resolve - mark a conflicted file as resolved
Belongs to the VCS plugin only.

> lock/unlock - lock a file or VCS resource
I'm unsure if needed and if most vcs systems have it.

> special - this should be available so clients may execute special
>           actions for a specific VCS system

This might make sense, altough it is somewhat against the idea to hide 
the VCS type. But to offer full power to the users, this is good to 
have (together with a getVCSinfo to actually find out what VCS system 
is used). Perforce's "integrate" could be a nice candidate to be 
performed with this.

tagging was mentioned in the thread. It is probably worth to have. But 
branching should (the actions can be different in VCS systems).

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. Similar signal could be 
an "aboutToSave" or "documentSaved" which can be used to create scripts 
that automatically commit your changes on save. This is weird, but 
might make sense. This is a little OT for the thread, but we will need 
such signals in other places as well to have the so called "event 
actions" feature from Quanta (you can assign actions -execute 
scripts/integrated actions, log the event, send email - to certain 
events like those I wrote up there).

Ok, I read only half of the thread, if I see something in the other half 
I will comment in a separate mail(s).

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/edfa4048/attachment.sig>