Where to populate Version Control entry

[Andreas Pakulat]

On 26.08.08 23:13:09, Evgeniy Ivanov wrote:
> Andreas Pakulat wrote:
> > On 26.08.08 02:43:56, Evgeniy Ivanov wrote:
> >> 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?

Version Control is for the most-often-used actions. We should try to
keep that submenu small. As I said we might even want to remove the 2
diff entries and make just one out of that.

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

Uhm, IBasicVC::add adds a file to a vcs system, its not meant to add
changes in a file to a commit - if the VCS system supports that. Thats
something that needs to go into a different interface, presumly IDVCS.

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

Well, personally I find it a lot easier to check the two or 3 files in
the commit dialog, then having to remember which files I need to "add"
to the commit before that. In fact in Eclipse I'm using the checkbox
stuff all the time instead of the "add" to add new files to svn.

Anyway, if you want an action to add a file to the list of
to-be-comitted changes you need a new action for that. "Add" is for
IBasicVC add, which only adds unversioned files to the VCS. I'll make
that clear in the api docs now.

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

Feel free to post patches or ideas as new mails.

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

Ok, here's the deal: Compare-to-HEAD only really makes sense with CVCS
or when comparing a local git repo against a remote git repo from which
you clone'd. Because the intention is to show what happened in HEAD -
compared to your current working version. So this compare mode should
even show differences if you don't have local modifications, but there
have been changes in the repository which you didn't sync yet (i.e. last
svn up is a while ago). I'd say this is something thats not used that
often. Whats used pretty often though is to check the modifications you
currently have on your disk - thats what svn diff does. It compares the
file on disk and a local copy from your last svn up - thats Compare to
BASE.

Hence I think we should have the "show local modifications" in the
context menu, everything else can be done via a more complex "Diff..."
action, which involves a revision-choosing-dialog to do the diff with.

Andreas

-- 
You dialed 5483.