Where to populate Version Control entry

[Andreas Pakulat]

On 26.08.08 02:43:56, Evgeniy Ivanov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andreas Pakulat wrote:
> > On 26.08.08 00:54:43, Evgeniy Ivanov wrote:
> >> I looked on what we have now.
> >> It doesn't work proper: if I have a hg repo and init git in any
> >> subfolder, then for subfolder items add will work with git only (and not
> >> with both hg/git).
> > 
> > This is not supposed to work. If you want to have special setups such as
> > this you're supposed to use the Git/Hg/Svn/Cvs/.. submenus, we obviously
> > need to provide the apropriate actions there too and enable/disable them
> > based on support inside the given directory/file.
> 
> Agree with it. But I didn't notice, it was hg project, but in dir with
> Git it used VS->add for Git (I didn't expect such behaviour). As you
> suggested some time ago it would be nice to use information from .kdev4
> about main plugin.

We already have that and it works pretty well IMHO :)

> Then create in VS menu only items for this plugin and
> in <VCS-name here> to create plugins depending on the if there are some
> extra repos.

Thats exactly what the TODO item in vcscommon talks about. Or rather
part of it. I'm not yet 100% decided wether we'll mandate the
project-setting for the general "Version Control" entry. Generally
having 2 VCS systems in the same project tree is a pretty uncommon
thing, so I'd say in 95% of the cases using the VC that controls the
directory of a file for the general "Version Control" submenu is ok.
People that mix VCS in the same directory tree will simply need to use
the VC-specific submenus.

> IMHO any active (used) VCS plugin should provide full list of facilities
> in one menu-item. I don't like having any [DC]VCS split into 2
> menu-items. Only init facilities can be separated.

You mean the various VCS-specific submenus should also have all the
actions? Yes thats right, especially if they have some special custom
options - like SVN allows to keep the lock when doing a commit.

> >> Also reading comment I found the thing that
> >> enabling/disabling will be very complicated:
> > 
> > Not _very_, just a bit more complicated than it is right now :)
> > 
> >> In DVCS add is always enabled.
> > 
> > Then your implementation of "add" is broken. Read the API dox of "add"
> > again, it clearly talks about putting the given location under version
> > control - not about adding them to the index file of git (in case of
> > git). For that you need a new action in the Git submenu.
> 
> Like checkout. In DVCS add has a bit another meaning, but add existed
> (there was no ICentralized that time) in IBasicVersionControl, so to not
> implement dummy add and add_dvcs I used it. We can have add in
> ICentralized and in IDistributed, but I don't think it's required (IMHO)

As I said, "add" is pretty well documented in IBasicVC and its a
required method that should work according to the documentation.
Anything else is a bug in the VC plugin implementing IBasicVC. If you
need a context menu action for adding to the index-file for all DVCS
plugins then this needs to go into IDistributedVC. And the entry should
make the difference clear.

But as I said elsewhere already I'm not sure you need that, as it should
be possible to do this implicitly using the commit-dialog.

> >> Also DVCS requires
> >> checkout/branch
> > 
> > That doesn't exist because so far no VCS system supported checking out a
> > different branch - or creating a branch.
> 
> Maybe I misunderstood you.

What I said was that until you did this for Git there was no plugin
supporting branching - in particular neither SVN nor CVS support this
today. Thats why there's no GUI yet setup for doing these things.

> I remember you tested  branch manager. Git supports branching.
> IDVCSexecutor supports any actions with branch/checkout (I didn't move
> it to IDistributedVC, because it isn't required to be there). Hg and
> bzr are in 5 minutes of supporting it too (I didn't implement it yet,
> just because was doing another things).

Well, there's already an interface that allows creation of branches and
tags. It might be specific to CentralizedVC systems right now, but it
would be cool if we could make it workable for both types.

> > I'm also not sure how we should handle that, for Svn and CVS you'll want
> > a toolview with a list of repositories and branch as well as checkout
> > will only work in there. And I'm tempted to handle DVCS the same way,
> > i.e. list the projects that are dvcs-controlled in the "repositories"
> > toolview and handle checkout/branching there.
> 
> I would suggest Branch Manager. IMHO it's ok: it can
> rename/create/delete/checkout to branches.

Except that it works only for local DVCS currently. I'm thinking of
having a toolview that uses our VCS interfaces to provide access to
differing repositories - remote or local. Its surely no problem to embed
the branchmanager as a starting point, but thats (hopefully) not our
final solution to repository browsing and branch-managing :)

> > The other option is to completely separate Dvcs and Cvcs.
> > 
> 
> Branch Manager can be moved to VCS/widgets: it require only list of
> branches and several API functions.

It requires a DVCS right now and doesn't work with the public API's
(read the interfaces in vcs/interfaces) - afaik (I haven't really looked
at the code much yet)

> >> /Compare to Index/Compare to Commit/etc
> > 
> > Those two should be in the Git submenu.
> > 
> >> (not all implemented yet). But some stuff from VCS should be disabled.
> > 
> > Which?
> 
> Compare to Base, Compare to HEAD, Update. First and third can confuse
> DVCS users, second can be used (to compare working copy with HEAD).

I agree about "Update", that one should be disabled when the plugin
supports IDistributedVC. 

I guess for DVCS a simple "show modifications" makes more sense than
Compare to Base/Compare to Head. In fact I'm not sure Compare to Head is
used often enough to warrant a separate entry in the general "Version
Control" menu.

One other problem we're facing: People can select multiple urls which
may belong to different VC systems. I'm wondering right now wether we
actually want to support this. In fact I think we don't, because DVCS
and CVCS are sometimes so different that you can't do meaningful things
with the same action on both types - except maybe commit/log/annotate.

> >> I can't suggest anything but to populate VCS in kdevvcscommonplugin and
> >> DVCS in dvcsplugin (for all 3 DVCS plugins).
> > 
> > Why?
> 
> Too many problems with populating menus for CVCS and DVCS in one place.

I don't really see any problems at all. Surely we'll need to do a few
special cases - but the problematic part is not implementing these
cases, the problematic part is finding out which cases need special
handling for DVCS vs. CVCS and finding a good way to present that to the
user. After all changing submenus is bad, same way its bad to have
multiple submenus that do mostly the same thing.

Andreas

-- 
You are fighting for survival in your own sweet and gentle way.