Commit dialog only lists file in editor for committing even though other files were modified

[Nicholas Allen]

If I have modified 2 files in a branch and select Team/Commit... from the context menu of 1 of the files only that file is shown in the commit dialog. Bzr-eclipse also indicates (rather misleadingly) that all files are shown via the check box "Check/Uncheck All".

When committing all files that have been modified in the current branch should always all appear in this dialog so the user can just check/uncheck the ones they don't want to commit.

[Guillermo Gonzalez (verterok)]

Hi Nicholas,

Thanks for reporting this.

I must say, that this is a feature not a bug. Let me explain it a bit more.. :)

When you choose commit from the context menu of a selected file (or from the menu bar with the focus in a editor or single file), the commit dialog only handle these selected resource (file in this case).

The "Check/Uncheck All" check box is not related to all the changes in the branch nor to all the resources in a project, it's just for the currently handled resources in the commit dialog, it's just a shortcut to check/uncheck all currently handled resources.

If you want to commit all changed resources from a project, the commit action should be called from the project itself. Same applies for all the changes files inside a specific folder.

I'm marking this as invalid, because this is the desired behaviour and also all the other team plugins (I used: CVS and subclipse/subversive) use the same approach.

[Nicholas Allen (nick-allen)]

This behaviour makes no sense whatsoever. Bazaar is a distributed version control system that works on branches. The default behaviour should match the intended use of Bazaar. I don't understand why listing all files in the commit dialog but only checking the ones the user selected is not a good compromise? Personally, I would rather they were all checked and I can uncheck the ones I don't want.

Commit is a branch operation and not a file operation. The chance that a change is only in one source file is slim to none and the user works in the editor when programming so when they select commit they don't want to commit some arbitrary random single file that the debugger happenend to open because of a break point.

I want a fast way to commit a branch with a keyboard shortcut and this should be the default behavior of commit in the menu bar. Having to select the project in project browser, right click and hunt down the commit action is practically unusable.

I really think this is completely incorrect and nonsensical behaviour. Could we at least bring this up on the Bazaar mailing list and see what other developers think about this? I think wider discussion on this would be useful.

This behavior is so wrong that I will be forced to fork bzr-eclipse if this behavior is not adopted and release my own separate version. Of course, I would rather not do this but if it's the only option then I will.

As you can see I feel quite strongly that this is absolutely wrong and definitely not a feature.

[Guillermo Gonzalez (verterok)]

Hi Nicholas,

Look at the inline comments.

On Sun, Aug 17, 2008 at 5:59 AM, Nicholas Allen
<email address hidden> wrote:
> This behaviour makes no sense whatsoever. Bazaar is a distributed
> version control system that works on branches. The default behaviour
> should match the intended use of Bazaar.

I think the behaviour should not match the bzr CLI one, and also
integrate into eclipse and ease the migration from other VCS plugins.
So, my point is that keeping consistency with other VCS plugins is
*important* and should help new users.

> I don't understand why listing
> all files in the commit dialog but only checking the ones the user
> selected is not a good compromise? Personally, I would rather they were
> all checked and I can uncheck the ones I don't want.

I never said it's not a good compromise, just that this is not a bug,
but a feature :)
I think that we can handle this special case at the preference level,
allowing both approaches to coexist.

>
> Commit is a branch operation and not a file operation. The chance that a
> change is only in one source file is slim to none and the user works in
> the editor when programming so when they select commit they don't want
> to commit some arbitrary random single file that the debugger happenend
> to open because of a break point.

I agree that commit is usually for multiple files/folders, but this
depends on the user :).
I don't know if you used other vcs plugins, but you usually don't
execute commit directly, The *key* part is still missing, and it's
the "Synchronize view". I plan to add this feature in the short term
(it's in the roadmap). Usually the wrokflow I see in other Eclipse
users is: run the "syncronize with.." and from there select what to
commit.

>
> I want a fast way to commit a branch with a keyboard shortcut and this
> should be the default behavior of commit in the menu bar. Having to
> select the project in project browser, right click and hunt down the
> commit action is practically unusable.

This is a totally valid request, and I'ld be glad to add it to the
roadmap. Please if you have a finished idea of what other features you
want, don't hesitate in writing a blueprint, or simply a draft in the
wiki (as a BzrEclipse/ subpage) so I can have a grasp of the general
idea.

>
> I really think this is completely incorrect and nonsensical behaviour.
> Could we at least bring this up on the Bazaar mailing list and see what
> other developers think about this? I think wider discussion on this
> would be useful.

I totally agree on discussing this and any other issues. But I don't
see the need this specific issue, because as I said before, this can
be handled at a preference level.

>
> This behavior is so wrong that I will be forced to fork bzr-eclipse if
> this behavior is not adopted and release my own separate version. Of
> course, I would rather not do this but if it's the only option then I
> will.
>
> As you can see I feel quite strongly that this is absolutely wrong and
> definitely not a feature.

I think that a if we work together, we 'll reach the best possible
solution to this.
Forking is completely valid (it's open source!!), but as I said, I'ld
prefer to...