6 comments

Hello,

I think, that most of the users spend more time modifying and commiting files rather then looking at the other's changes, so to reduce visual clutter in, let say, 80% of the time "TMate-Changes" is a separate window - it has not tabs and status bar providing more space for the files, while "Tmate" window already has three tabs and status bar.

May I ask you what is the benefit, from your point of view, of displaying "Changes" window as a tab in "TMate" window? I may add an option to the plugin if it makes sense for some of the users.

Thanks,
Alexander Kitaev.

0

Alexander Kitaev wrote:

Hello,

I think, that most of the users spend more time modifying and commiting files rather then looking at the other's changes,


Interesting. Its just the opposite for me. I have not used the
"TMate Changes" much other than for a quick look at what is modified.
But I get that same info from the "CVS Files" view. Also I always commit
all files in the project at once (as part of an XP-style delivery), so
the "Commit Project" is usually what I use.

Maybe you could give a quick summary of what you see as the benefits of
"TMate-Changes" over idea's "CVS Fileview" and other cvs actions.

... "TMate-Changes" ... it has not tabs and status bar providing more space for the files, while "Tmate" window already has three tabs and status bar.


I was thinking that "TMate-Changes would be better placed as one
tab within the "TMate" panel. ie, "TMate" would have four tabs. Agreed,
it would provide less space for files since the status bar
would be taking up space along with tabs. Also, if you plan for
"TMate-Changes" to ever be multi-tabbed, this would probably not work out.

May I ask you what is the benefit, from your point of view, of displaying "Changes" window as a tab in "TMate" window? I may add an option to the plugin if it makes sense for some of the users.


I guess I'm trying to reduce the clutter of the tab/buttons that open
the panels/windows. I use a lot of plugins so there a lot of buttons at
the bottom of my idea window. Its also kinda confusing to have TMate
buttons seperated from each other (eg, SQL and CVS Fileview might be
between "TMate-Changes" and "TMate". Another thing that is somewhat
confusing is the names "TMate-Changes" and "TMate". "TMate" is so
general I would expect all "TMate" functionality to be found there.

In any case this is no big deal. If you have new functionality planned,
don't waste much time with this.

thanks!!

-bk

0

Maybe you could give a quick summary of what you see
as the benefits of
"TMate-Changes" over idea's "CVS Fileview" and other
cvs actions.


With pleasure :)

- Takes less space on the screen allowing to see more files at once.
- Allows to group changed files by any number of change sets with different names and commit or rollback those sets separately, any change set can be marked as "default", so newly modified files will be added to it. If you ever worked with Perforce VCS it may be similar to perfoce change sets view that includes both transactions made by other users and "open" files that are not commited yet.
- Provides support for autoscroll and ctr-alt-up/down arrows navigation
- Updates itself more correctly then "CVS Files View", so user virtually doesn't have to click "Refresh" which is not the same for "CVS Files View"
- Supports predefined "Default" and "Excluded" change sets and provides "Insert" and "Delete" key strokes support, so it combines "CVS Files" view and "Commit Project" dialog

Personaly I'm using only "TMate-Changes" window to view and commit modified files and find it more useful then "Commit Project" dialog and "CVS Files View" combination, but your ideas about how it could be improved and what is missing there are very welcome!

Later, I'm planning to extend this view with the list of transactions that are catched by the TMate Server but not synced with the active project yet, and add JIRA tracker integration that will allow to select commit messages from the open JIRA issues names.

If you are not using TMate-Changes window you may hide it, so its button even will not be displayed in the IDEA buttons bar.

There also plans to change "TMate" window layout, so that space problem will be solved and it will be possible to convert "TMate-Changes" window into the separate tab in "TMate" window. I'm not completely sure that it will be possible, but there are some chanses :)

Thanks,
Alexander Kitaev.

0


Alexander Kitaev wrote:
>>"TMate-Changes" over idea's "CVS Fileview" and other...

- Allows to group changed files by any number of change sets with different names and commit or rollback those sets separately, any change set can be marked as "default", so newly modified files will be added to it. If you ever worked with Perforce VCS it may be similar to perfoce change sets view that includes both transactions made by other users and "open" files that are not commited yet.
- Supports predefined "Default" and "Excluded" change sets and provides "Insert" and "Delete" key strokes support, so it combines "CVS Files" view and "Commit Project" dialog



Hmm, I did not notice this, let me see if I understand:

I'm working a task, some files get modified. Now I'm done with task so I
add those files to a change set (or had the change set already marked as
default). Instead of delivering those files (ie, commit to cvs) I work
on another task and mark those modifieds as a different change set. Now
I can commit the two sets of files seperately.

Personaly I'm using only "TMate-Changes" window to view and commit modified files and find it more useful then "Commit Project" dialog and "CVS Files View" combination, but your ideas about how it could be improved and what is missing there are very welcome!


Yes, I usually use smartcvs. The idea cvs fileview has tons and tons of
wasted space. The idea commit tree view is way too noisy and way too
big. I'll try using tmate for a while instead of smartcvs and and see
how I like it. The only downside I see with it for this purpose is the
tree view that splits the files across modules -- I prefer a flat view.
(I had to lobby long and hard with jebrains to get a flat cvs fileview.)


Later, I'm planning to extend this view with the list of transactions that are catched by the TMate Server but not synced with the active project yet, and add JIRA tracker integration that will allow to select commit messages from the open JIRA issues names.


That would very nice.

If you are not using TMate-Changes window you may hide it, so its button even will not be displayed in the IDEA buttons bar.


I never knew you could do that! Thanks. But I really don't want to get
rid of it, I just wanted to have only one TMate button.

There also plans to change "TMate" window layout, so that space problem will be solved and it will be possible to convert "TMate-Changes" window into the separate tab in "TMate" window. I'm not completely sure that it will be possible, but there are some chanses :)


Ok. Thanks much!!!

-bk

0

Hello,

+Hmm, I did not notice this, let me see if I understand:
I'm working a task, some files get modified. Now I'm done with task so I add those files to a change set (or had the change set already marked as default). Instead of delivering those files (ie, commit to cvs) I work on another task and mark those modifieds as a different change set. Now I can commit the two sets of files seperately.+

Exactly! Also you may easily iterate through the changed files related to a certain task or rollback modifications made for a particular task. I usually work on some large feature, and in the meantime fix (or start to fix) smaller problems in the different parts of the program. I put these minor changes into additional change sets not to forget what changes are related to what and to be able to rollback some of the changes later (i.e. fix that doesn't work or some experimental code).

+how I like it. The only downside I see with it for this purpose is the tree view that splits the files across modules -- I prefer a flat view. +

There are plans to add a toggle button that will display modified files as a flat list of absolute file names, without "module" nodes. (There is already similar grouping option in TMate window).

(I had to lobby long and hard with jebrains to get a flat cvs fileview.)
I agree - there is absolutely no need for a deep tree if there are relatively small number of related files to display.

+> If you are not using TMate-Changes window you may

hide it, so its button even will not be displayed in
the IDEA buttons bar.

I never knew you could do that! Thanks. But I really don't want to get rid of it, I just wanted to have only one TMate button.+

You also probably would like to know that there are two actions in TMate plugin that available from the main menu - "Toggle TMate Window" and "Toggle TMate-Changes Window". Default shortcuts are Ctrl-Shift-T and Ctrl-Shift-K. These actions toggles TMate windows completely removing them if they are shown and focused or bringing them back to front if they are disabled or not focused.

Thanks,
Alexander Kitaev.

0


Alexander Kitaev wrote:

Hello,

+Hmm, I did not notice this, let me see if I understand:
I'm working a task, some files get modified. Now I'm done with task so I add those files to a change set (or had the change set already marked as default). Instead of delivering those files (ie, commit to cvs) I work on another task and mark those modifieds as a different change set. Now I can commit the two sets of files seperately.+

Exactly! Also you may easily iterate through the changed files related to a certain task or rollback modifications made for a particular task. I usually work on some large feature, and in the meantime fix (or start to fix) smaller problems in the different parts of the program. I put these minor changes into additional change sets not to forget what changes are related to what and to be able to rollback some of the changes later (i.e. fix that doesn't work or some experimental code).


Ok, this makes sense. However, for our process (mostly XP) we could not
do that, since /all/ tests must pass prior to a delivery (cvs commit),
whch cannot be guaranteed if some changed code is in the workspace but
did is committed after running the tests. To do what you do, we need to
checkout another workspace. But I see the value of the feature if you
are working in a non-XP process.

0

Please sign in to leave a comment.