There has been some discussion on this list about using changelists
and several requests to make it easier to add unmodified files to a
changelist.
Would it be possible to use the changelist headings in CfM as a drag
and drop target so that files could be dragged from explorer into a
changelist? Or from one changelist to another within cfm or commit?
In cfm you can either show all unmodified files or none. If you are
using changelists then unmodified files within changelists would be of
much more interest than the zillions of other unmodified files, so can
I suggest either always show unmodified files if they are in a
changelist, or make the check box tri-state so that it has
no-unmodified/unmodified-in-changelist/all-unmodified states. I think
the first option would be good enough, and it would be consistent with
the CLI. Cfm is our equivalent of svn status, which now shows all
changelists.
Related to this, changelists that contain only unmodified files are
not shown unless you also show modified files.
Within cfm it seems that (no changelist) is always listed first,
followed by the user changelists. Looks like they are sorted in
case-sensitive alphabetical order. It seems more logical to me to give
user lists highest priority, then (no changelist) and lastly the
ignore-on-commit changelist, if the Windows API allows you to set the
order.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-uns...@tortoisesvn.tigris.org
For additional commands, e-mail: dev-...@tortoisesvn.tigris.org
working on it...
> In cfm you can either show all unmodified files or none. If you are
> using changelists then unmodified files within changelists would be of
> much more interest than the zillions of other unmodified files, so can
> I suggest either always show unmodified files if they are in a
> changelist, or make the check box tri-state so that it has
> no-unmodified/unmodified-in-changelist/all-unmodified states. I think
> the first option would be good enough, and it would be consistent with
> the CLI. Cfm is our equivalent of svn status, which now shows all
> changelists.
As of r12485, items which are in a changelist are shown in the CfM and
commit dialog even if they're not modified.
> Related to this, changelists that contain only unmodified files are
> not shown unless you also show modified files.
>
> Within cfm it seems that (no changelist) is always listed first,
> followed by the user changelists. Looks like they are sorted in
> case-sensitive alphabetical order. It seems more logical to me to give
> user lists highest priority, then (no changelist) and lastly the
> ignore-on-commit changelist, if the Windows API allows you to set the
> order.
changed the order in r12488.
Stefan
Implemented in r12494.
Stefan
This is minor, but I am not so sure it is a good change.
For example, I typically use changelists as a kind of "stash" feature,
when I move unfinished, not-ready-to-commit-yet changes in a separate
changelists to untangle them from the current work.
In this case, it is better to show files without changelists first.
No idea how common my usage pattern will be, though.
Of course, I totally agree that 'ignore-on-commit' changelist should come last
in any case.
--
Alexander S. Klenin
Insight Experts Ltd.
Not sure about this one.
Another point is that if you use changelists a lot then your proposal
would ensure that anything you forgot to add to a changelist appears
right at the top where you will notice it. But that is similar to
saying that unversioned files should come first in the commit dialog
so you don't forget to add them, so that is no guide either.
I think we should wait until we get some feedback from RC1 when that comes out.
> Of course, I totally agree that 'ignore-on-commit' changelist should come last
> in any case.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
Tested r12494 on XP and the drag & drop doesn't seem to work, either
dragging items from explorer into a changelist, or from within CfM
dragging items from one changelist to another.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
It works in the commit dialog :)
Enabled it for all dialogs using the CSVNStatusListCtrl in r12512.
Stefan
Thanks. Just tested in the commit dialog with r12494 and found a couple of bugs.
1. With no files in a changelist, right click on the file at the top
of the list and add to a new changelist. When the view redraws, all
files appear below the new changelist header. If you close the commit
dialog and reopen it, only the file that you added is really in the
changelist, so it is just a display bug.
2. Drag and drop onto the header works, but drag and drop onto another
file brings up a copy icon []+. Nothing happens when you drop there,
but the view refreshes which makes it look as if something unexpected
might have happened. It would be better if the header was the only
drop target.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
Simon Large wrote:
| Thanks. Just tested in the commit dialog with r12494 and found a
couple of bugs.
|
| 1. With no files in a changelist, right click on the file at the top
| of the list and add to a new changelist. When the view redraws, all
| files appear below the new changelist header. If you close the commit
| dialog and reopen it, only the file that you added is really in the
| changelist, so it is just a display bug.
Fixed yesterday - try todays nightly build.
| 2. Drag and drop onto the header works, but drag and drop onto another
| file brings up a copy icon []+. Nothing happens when you drop there,
| but the view refreshes which makes it look as if something unexpected
| might have happened. It would be better if the header was the only
| drop target.
I know. Not sure how to 'fix' this yet.
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFH8dyINTJADUWeLT4RAtEvAKCv0iP2SAkEqr2ZgfkeMmEvDIyJpACfSJPe
JGIrATdLsENRE+7pQIZ5t68=
=duFh
-----END PGP SIGNATURE-----
> 2. Drag and drop onto the header works, but drag and drop onto another
> file brings up a copy icon []+. Nothing happens when you drop there,
> but the view refreshes which makes it look as if something unexpected
> might have happened. It would be better if the header was the only
> drop target.
Fixed in r12526.
Stefan
I agree with Alexander. I would like to see files without changelists at the
top.
I use changelists to stack unfinished work. If a modified file is appended
to the end of the list the chance that it will be overseen increases.
Btw, I think showing unversioned files at the top is a good idea. Those
files should either be "SVN added" or "SVN ignored" so it might be
helpfull to show them at the top of the list until the user has decided
what to do with them.
I don't mind waiting for RC1 before we change this. Let's hope we get so me
more feedback.
Tobias
You won't want to hear this, but this sounds like a candidate for a
checkbox in the settings dialog. Not sure whether both (no changelist)
and unversioned files should be handled by the same setting.
Simon
> You won't want to hear this, but this sounds like a candidate for a
> checkbox in the settings dialog. Not sure whether both (no changelist)
> and unversioned files should be handled by the same setting.
I would still need to agree on a default :-)
But you're right: I'm against having yet another setting.
I would prefer to have a sensible default which can be changed by a hidden
registry key. If enough people request it we can still put a checkbox in
the settings dialog.
Are there any other opinions out there?
Tobias
As of r12593, files which are not assigned to a changelist are shown on
top. But without a setting or hidden registry.
Stefan