Re: [Monotone-devel] eclipse plugin progress report

[Georg-W. Koltermann]

Daniel Carosone wrote:
> On Thu, Jun 22, 2006 at 10:15:43PM -0700, zi bin cheah wrote:
>   
>> Wat do you mean? refactoring of files that is attached
>> to workspace causes error when a person uses shell to
>> mantain it?
>>     
>
> Java has lots of conventions (or stronger) about class and package
> names and file paths/names.  If you rename a class, that renames the
> .java and other files (and even the directory structure) accordingly.
>
> Eclipse will do all of this for you easily, and many of these
> refactorings can be heavily automated - it would be nice if the
> eclipse plugin could register these changes automatically, because
> even knowing what they all are can be hard, let alone trying to
> reproduce them in parallel with a bunch of manual "monotone rename"s
> being very tedious.
>   
That's certainly true, and I would be absolutely happy seeing those
changes automatically propagated to monotone.

But in practice, in my experience (being a Java programmer) class and
package renames are rather rare as the product matures. I tend to rename
often during the early experimental phase, but at that point I'm not
concerned about history tracking of renames so much, I'm more concerned
about the ability to go back a few revisions at that stage.

Later on refactorings more often extract a part of a class into a new
one to reduce complexity / increase modularity.  That cannot be easily
modeled in monotone I believe.

Looking at practical day to day use, some other functionalities are more
important to me are:

    * navigating code history line by line (e.g. "annotate" view, if
      possible with +/- buttons to scroll forward/backward in history
      and annotate the next/previous version of the same file)
          o color coding a la Emacs blame would be really nice :)
    * comparing versions of the tree or versions of a file graphically
      within Eclipse
          o at least comparing the current tree to the base version in
            monotone
    * using Eclipse for conflict resolution during merges (this would be
      just sooooo cool, you could even see if the merge you did at least
      compiles!)

I'm also not too concerned about checkout/commit integrated in Eclipse. 
It would be nice, but it doesn't hurt too much to do that on the command
line.

There is some stuff that can be easily achieved externally, e.g. for
workspace updates you can, as an end user, just add a shell command
doing "mtn up" to the run menu.  Same for "mtn log".  Not too nice,
since they will output to the console, but still quite useful.  So in my
opinion that kind of stuff could be deferred implementation for the plugin.

Maybe I'm asking too much, dunno...  I once tried to colorize the
annotation  support that the SVN Eclipse plugin provides, and felt
completely lost. Eclipse is just such a complicated world to understand
for a newcomer.  Feel free to share any nicely understandable
introduction to that matter with me, I'd be glad if I at least understood

Thanks a lot and keep up the good work.  Let me know when you are ready
to share first versions of the code.

--
Regards,
Georg.

smime.p7s
Description: S/MIME Cryptographic Signature