Patch for preliminary Mercurial integration in kdevplatform

[Evgeniy Ivanov]

On Mon March 16 2009 23:52:26 Fabian Wiesel wrote:
> On Mon, 16 Mar 2009 13:44:33 +0300
>
> Evgeniy Ivanov <pfx.kde at gmail.com> wrote:
> > On Mon March 16 2009 11:01:07 Fabian Wiesel wrote:
> >
> > In IBasicVCS meaning of add is "add file to the repository". In DVCS
> > it's meaning is "Add file contents to the index" (and also add to
> > repository for files outside).
>
> I think, that is a peculiarity of git (or should I say another?).
> hg add works the same way as svn,cvs,bzr and darcs. Non-tracked files
> are added to the files to be tracked.
>
> If I understood Andreas correctly, git simply adds another meaning to
> add:
> Mark modified files to be commited with the next commit. This simply
> duplicates the functionality of commit, as the git manual entry itself
> states.

Not at all. Result of git add is an object representing file in git 
repository. If you will do git add 3 times before commit you will have 3 
objects representing added files, but only the last will be added to the tree 
object (which is tied with commit object). Another add-objects will become 
dangling and will be removed in some amount of a time (AFAIK depending on your 
settings).
There are some interesting things you can do with these objects: for example 
fix damaged repository (don't do dirty things with command line and you will 
not get into trouble :P ) or undo changes even if you haven't committed yet.

> > There was some long discussion (Andreas, Alexander (Dymo) and I) and
> > we decided to separate these things (I still think that in DVCS case
> > "add" should be in menu for both actions).
>
> Maybe you can name me the deciding point, which lead to that decision.

As Andreas mentioned: unifying menus and making life easier for users.
I agree that items should be named in one way, but I like N-menus instead of 
one (I fully support your initiative to push Andreas to the new (which is 
actually old) layout of VCS menus :) ).

> I have the feeling, that several people think, that DVCS are
> much more different from CVCS than they really are. In essence, they
> simply are local VCSs (-> init) with the possibility of pushing changes
> to a passive receiver (push), or pulling them from another (pull).
> Due to their distributed nature, they have to understand parallel
> branches of changesets. This lead to the advent of in-tree branches.

That was one of the reasons.

> > > Except it doesn't work with mixed VCSs.
> >
> > There is an easy solution: have all things not only in main menu, but
> > also in all DVCS menus. Until we get VcsCommonPlugin situation was
> > the same, so I used several VCS for project.
>
> I don't quite understand, how this solves the problem of multiple VCSs.
> Which "commit" will be called in the common menu?

Common menu should die in this case :) And main VCS should be marked in menu 
with separator.

>
> > [...]
> > AFAIK VcsCommonPlugin does some caching.
>
> Well, I get called for each and every file I right click. And the worst
> of it is, it has to be that way. VcsCommonPlugin cannot cache it in a
> sensible way, as it doesn't know, when something has changed in the
> repository. This is VCS specific.

Everything in {the repo / not in the repo} until add/remove is done. Thus 
VcsCommonPlugin can update cache on some signals from VCS plugins.
Since we just need to know if item is versionControlled then we don't care 
about changes, but care about add/delete.
AFAIK it's doing caching for items in projectview (so shouldn't check again 
for the same dir).
But agree you can do caching in isValidDirectory() (isVersionControlled). It 
doesn't look very hard with my suggestion about add/remove signals.

> > In DVCS case we really can keep repo's root to use it in
> > isValidDirectory().
>
> This works for git and mercurial, but I won't claim that it
> will work for others, too. In fact, bzr seems to actually track
> directories. So, you can have an untracked directory in a tracked one.
>
> >  Then "Add" should be enabled (AFAIK it is)
> > independent on file is already controlled.
>
> It is, and it is annoying. Adding is not a sensible operation on a
> file, which already has been added.

As a git user I woudn't understand (without reading our mails) why "Add" is 
disabled. Better to remove it away.

> > And "Remove" should always
> > shoot and in case file is not controlled we can show failure dialog
> > (in our case "git/hg" will finish with cute status).
>
> While this is quite work efficient solution and I don't intend to
> change that any time soon, I believe that this also contradicts every
> Human Interface Guideline in existence :)
> I hope, you just wanted to point out, that it doesn't break anything and
> therefore shouldn't have a high priority. On that, I certainly can
> agree.

Sure. If you can't remove a file, you shouldn't see remove item in menu.


-- 
Best regards, Evgeniy.
Key Fingerprint: F316B5A1F6D2054FCD18B74A95400ABB1FE567A3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090317/4572b7d0/attachment.sig>