Eugene Kuleshov wrote:
> First of all it is not about CVS, but about generic Team
> infrastructure. Unfortunately it had been mostly used for CVS plugin,
> but there are lot of ideas and features already in place ready to be
> picked up and used.
> Let me enumerate what you are trying to do in that modal commit dialog:
> 1. See list of changed files/properties
> 2. Select some of those files for commit
> 3. Be able to see changes (open comparison tool) for each of those files.
> 4. Prepare comment for commit
> Did I miss anything?
> Anyways, all of those actions can be done from Synchronize view and
> all of them (exept entering commit comment) can be done without a
> single dialog (comparison tool is an editor I was talking about in my
> previous email).
Heh. You didn't miss anything. Except the point. :-P I like the fact
that you can click on a file in the sync view and have it automatically
open in the compare editor*. That's swell. But you glossed over the two
salient points I was asking for comment on. Basically #2 and #4.
*I use the commit dialog quite a bit, it's nice to be able to see the
"diff" from there now ;-)
> You should really learn in depth how those things are done for CVS
> plugin before going into discussion. I've been using both Subclipse
> and CVS in Eclipse long enough to say that Eclipse CVS integration is
> most convenient and rock solid one I ever seen (from the feature set
> and UI ergonomics) and Subclipse is still have to catchup with that.
> Major missing features are incoming and outbound change sets.
Yes, I agree, the CVS implementation within eclipse is second to none.
Commit sets _are_ great. They are also far from trivial to implement.
What about refactoring? How inter-woven with the IDE are you gonna get?
How far does that get you from Subversion?
There have been good things added to the Eclipse API in later
versions, for stuff like commit sets (indeed, team things in general),
that would be a pain (understatement?) to support in earlier versions of
Eclipse. So I guess I was thinking more of UI type of stuff, things
that could be back-ported pretty easy or whatnot.
Specifically the modal nature of the commit dialog... but generally
the way the data of that type is best represented to the user... sort of
that asynchronous vs. synchronous type of deal, or whatever.
But commit sets are a great example - You can take the knowledge of what
you have learned from using CVS's commit sets, and apply that in a fresh
way, only better, with SVN. Same goes for commit dialogs or even how
resources are viewed- what info is immediately available vs.
sub-menuable or SomeOtherView-able. CVS has been around a little longer
than SVN (except for commit sets *cough*).
Funny that you are against adding / changing views yet at the same time
request a new "view" and then some.
Sounds sorta like one of those "forget that stuff that you are
interested in, I have a feature I want" type of deals...
...which isn't a very "open" attitude. :-P and besides that, isn't what
I was asking about.
And that's way out of my league. Adding filename completion or
tie-ing in the built-in spell checking stuff to the commit dialog is
more my speed. Course, what's available depends on context, neh? Or
something like that. Basically I'd think an "editorPart" would be easier
to tie in than a dialog text box, but I haven't even looked into it.
Might not matter one wit. I just thought I'd stick my finger in the air
sorta and see how the wind was blowing UI wise. But I was looking for
some real wind, vs. comments to the effect that I should check out the
I agree, there are oodles of great things going on therein. The
type is made up of many type. Funny- collective nouns... the team are,
the team is... wrap your head around what that means. People have
totally different concepts of if a collective noun is one entity or
not... objects, categories, concepts... linking them all... wow, that IS
far out. There _is_ a method to the madness! Order and chaos are
bedfellows! How gay does bedfellow sound? Bah. Now I'm just typing
whatever comes to mind, instead of whatever it was I was, oh, yeah,
I'm not very professional, my apologies. I must be obsessive, cuz did
this post warrant such a heinously long reply? Who can say- life is so
weird and all that.
Anyways, that's all I got. I know, I know, you're thinking "please
denny, just a little more. One more pearl, com'on dood, you can do it.".
:Denny [rag'n =]
> Denny Valliant wrote:
>> Eugene Kuleshov wrote:
>>> Guys, maybe you should stop inventing new view and fooling around
>>> with those dialogs? It is all already there.
>>> View you are looking for is called Synchronize view and it is
>>> provide all the infrastructure to see changes and call comparison
>>> With a correspond data provider it would also allow to group
>>> outgoing changes together before committing (either manually or
>>> using some tools, e.g. Mylar).
>> That's swell Eugene, I love the sync view, but you'll find I was
>> talking about something sorta different. It really stems from your
>> observant comment about _editors_. There are sync options that
>> require editing (or grouping, or whatever). I don't have any trouble
>> with extending the sync view more, that would be a logical place to
>> do it.
>> So I assume you favor a pane or some such that splits the view and
>> contains space for writing log text or whatever? Or what? I was
>> looking more for ideas, like specific ideas, vs. another general
>> idea. Sure we have a sync view, and that is a logical place to put
>> sync related info, but *how* would you use the sync view instead of
>> the dialogs or a different view or whatever? See what I mean?
>> Looking for actual ideas that could have pro's and con's discussed
>> and whatnot.
>> Like, what you could have said was, "Hey, I understand what you are
>> talking about with the modal dialogs and such, and I've been thinking
>> about it too, and I think that the commit dialog could be a split
>> pane in the sync view vs. the current dialog." I doubt that's what
>> you meant, but you get the drift... or "I happen to really like the
>> modal dialogs and think they should stay" or whatever...
>> I don't think we have to do everything the way CVS does it either, so
>> I'm not gonna say something is good just because that's the way it's
>> been done before, or whatever. I'm looking for practical, intuitive,
>> whatnot. Same crap everyone wants. Not that I'd do anything with any
>> practical ideas or whatever, I just wanted to see what you thought.
>> Seriously tho, ya know, actual "we could do it like this, or like
>> that, or like this and uh" type suggestions. So they could be torn
>> apart or whatever and I'd get some knowledge and maybe we'd come up
>> with ideas that are in the middle enough so they're useful to a wide
>> audience and don't go against the grain of SVN and whatnot.
>> I know you've got some ideas Eugene, if you aren't too invested in
>> them, I'd like to hear what you got...
>>> Denny Valliant wrote:
>>>> Mark Phippard wrote:
>>>>> "Jesper Moller" <email@example.com> wrote on 01/27/2006
>>>>> 10:10:03 AM:[...]
>>>> > I have a different idea which I put into
>>>> > the bug report, to make a new compare
>>>> > dialog (which is neccessary anyway to
>>>> > fix the issue with the file being editable
>>>> > and the wrong buttons) which also has
>>>> > a commit message edit field, so you
>>>> > could "carry the text around" while
>>>> > looking at the diffs for each file.
>>>> It could be the commit view!
>>>> Then throw in spell checking, class/file
>>>> name completion, and a bunch of other
>>>> stuff for the log text! :-)
>>>> :-) I love the patch.
>>>> I had this sitting in "Drafts" and thought
>>>> what the hell, it's an idea. The comments
>>>> about the latest patch submission (thanks
>>>> author of patch:) for unversioned resources
>>>> got me to thinking that maybe Mark was
>>>> onto something when he was talking about
>>>> getting rid of the modal dialog... and thus,
>>>> why not send this out, as an idea? A view
>>>> for the various actions vs. the dialog?
>>>> Eh. Guess the hard part is the design, not
>>>> the idea, but I'd like to second the nixing
>>>> of the modal dialog... or maybe keep
>>>> the dialog, but add a view, where we
>>>> could stick some features that the dialog
>>>> doesn't have space for? "Extended"
>>>> actions maybe? Something like that?
>>>> I was just liking the idea of non-modal
>>>> but having trouble concieving how, and
>>>> thought, hey, maybe Mark or someone
>>>> else has thought of a philosophy regard'n
>>>> the idea, or whatever.
>>>> If that was Mark that proposed it even.
>>>> Just idle thoughts, sorta...
> To unsubscribe, e-mail: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Feb 7 08:57:16 2006