Where to populate Version Control entry

[Evgeniy Ivanov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Pakulat wrote:
> 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 :)

Didn't notice. Will look on vcscommonplugin. But everything really works :)

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

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

No, "Version control" submenu. Can I add switch to vcscommon?


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

It also adds files to the repo. There is no reason to have several add()
methods doing the same thing: <dvcs> add file1 file2.
I changed documentation for IBasicVC pointing to it.


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

It can be useful. If I did change I want to be committed with next
commit I would like to have add (rather then watching the full list in
commit dialog). Also it will be in commit dialog with "C" (cached), so
it will make my life better.

>>>> 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.
> 
> 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 will try to change branch manager to implement this interface. But I'm
not sure it's convenient for current branch manager.

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

Sure. Adding remotes, etc is not supported yet. Also I don't have
push/pull. All these things can be gathered in one toolview.

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

When I commit I like to use ~ "Compare to HEAD". It shows all
modifications between HEAD and working directory (not only cached).
It can be "show all modifications". But "Compare index and HEAD" is
useful too.

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

You're right. But no ideas right now.

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

True. Will use special cases.

- --
Cheers, Evgeniy.
Key fingerprint: F316 B5A1 F6D2 054F CD18 B74A 9540 0ABB 1FE5 67A3

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAki0VcUACgkQlUAKux/lZ6NGPwCePLMAfkGOLwcaGd8DJfBSdf1x
x8IAnRcyA1GuSV7Drr+kcLf78Ny6ggx3
=pf1B
-----END PGP SIGNATURE-----