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
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel