Hi,
it is possible to sort results of comparison by a column header (by a file
size for example). Very handy in general but the problem is that if the
sorting is selected in one window, the second should follow the same sorting
method, but it does not. If the comparison reports matching files that need to
be updated on any side it works fine, but if files are renamed and need to be
deleted and copied as a new file the sorting does not work as expected (FFS
3.6):
- in the window where sorting was selected it is sorted correctly (e.g. by file size)
- in the second window deleted files are at the end of the list regardless of their size (or any other attribute used for sorting)
That is clear that if file was modified (and has a matching copy awaiting for
updating) the date of it or the the file size cannot be fully respected when
files are sorted (in one row the matching files MUST be displayed regardless
of a sorting method). The sorting could be improved for files not having a
matching copy. It would greatly improve analyzing files which changed their
name only, in two consecutive rows we would have a deleted file and a new
instance of it (under a new file name).
A related issue is that after comparison the files are sorted by their path,
but it does not give the same result as clicking the 'relative path' header to
force sorting by a path. The default sorting method (path, then filename) is
very close to the optimal one, but it gathers together first files which need
to be copied to the other side and then gathers together files which need to
be deleted on the other side (copy copy copy..., delete delete delete...). A
better way would be to interleave the operations (copy delete, copy
delete...).
thanks for any help,
szumu
Sorting by filename, size, date
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
Hi,
the sorting sequence always considers only the selected side in the following
order:
1. existing files: sort according to size/date/etc.
2. directories: sort by name
3. empty entries
> A better way would be to interleave the operations (copy delete, copy
delete...).
Considering both sides while sorting may be useful when trying to find renamed
files, but in general having a lot of holes in between is a bit confusing.
> does not give the same result as clicking the 'relative path'
That is because after comparison all entries are more or less unsorted and
resemble the order in which the files have been read from disk.
Regards, Zenju
the sorting sequence always considers only the selected side in the following
order:
1. existing files: sort according to size/date/etc.
2. directories: sort by name
3. empty entries
> A better way would be to interleave the operations (copy delete, copy
delete...).
Considering both sides while sorting may be useful when trying to find renamed
files, but in general having a lot of holes in between is a bit confusing.
> does not give the same result as clicking the 'relative path'
That is because after comparison all entries are more or less unsorted and
resemble the order in which the files have been read from disk.
Regards, Zenju
Hi,
thanks for your response.
the program is really great yet I can see a possibility to slightly improve
it. I hope the modification would be rather cosmetic but would give a
functionality to identify the renamed files. The renamed file would not be in
one row on both sides but in two consecutive rows (one file out, one file in).
> the sorting sequence always considers only the selected side..
I can see it it and it is fine, but at the same time the other side is
resorted as well and to be honest not quite consistently, i.e. the order of
files on the other side depends somehow of how it was sorted before, but not
fully (I mean the files corresponding to empty entries on the selected side).
>Considering both sides while sorting may be useful when trying to find
renamed files, but in general having a lot of holes in between is a bit
confusing.
By default, just after the comparison, there are holes anyhow, I do not find
them confusing, quite opposite. The holes are per folder rather per file what
IMO would be much better for renamed fies. Unfortunately after selecting any
further sorting method it is not possible to revert to the default order of
files with 'holes' (unless the comparison is executed again).
At present it is pretty hard to distinguish between a deleted file and a
renamed one (or a moved one). Having interleaved rows with deleted files and
copied under new filenames would change the situation a lot.
I wonder if other users of FFS would find a possibility to identify renamed or
moved files useful.
regards,
szumu
thanks for your response.
the program is really great yet I can see a possibility to slightly improve
it. I hope the modification would be rather cosmetic but would give a
functionality to identify the renamed files. The renamed file would not be in
one row on both sides but in two consecutive rows (one file out, one file in).
> the sorting sequence always considers only the selected side..
I can see it it and it is fine, but at the same time the other side is
resorted as well and to be honest not quite consistently, i.e. the order of
files on the other side depends somehow of how it was sorted before, but not
fully (I mean the files corresponding to empty entries on the selected side).
>Considering both sides while sorting may be useful when trying to find
renamed files, but in general having a lot of holes in between is a bit
confusing.
By default, just after the comparison, there are holes anyhow, I do not find
them confusing, quite opposite. The holes are per folder rather per file what
IMO would be much better for renamed fies. Unfortunately after selecting any
further sorting method it is not possible to revert to the default order of
files with 'holes' (unless the comparison is executed again).
At present it is pretty hard to distinguish between a deleted file and a
renamed one (or a moved one). Having interleaved rows with deleted files and
copied under new filenames would change the situation a lot.
I wonder if other users of FFS would find a possibility to identify renamed or
moved files useful.
regards,
szumu
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> the other side is resorted as well
The other side is not actively considered during sort. Therefore any
reordering is random.
> depends somehow of how it was sorted before
Most of the time I'm using a stable sort. Rows that are considered equivalent
are not reordered. Therefore all rows that fall into category 2 and 3 are not
reordered.
Additional note: There is a logical issue when sorting respects both sides.
For example the following cannot be sorted according to both sides:
Size 10.000 - Size 20.000
Size 20.000 - Size 10.000
<empty> - Size 30.000
> I wonder if other users of FFS would find a possibility to identify renamed
or moved files useful.
They do:
[404, Invalid URL: http://sourceforge.net/tracker/?func=detail&aid=2880632&group_id=234430&atid=1093083]
The other side is not actively considered during sort. Therefore any
reordering is random.
> depends somehow of how it was sorted before
Most of the time I'm using a stable sort. Rows that are considered equivalent
are not reordered. Therefore all rows that fall into category 2 and 3 are not
reordered.
Additional note: There is a logical issue when sorting respects both sides.
For example the following cannot be sorted according to both sides:
Size 10.000 - Size 20.000
Size 20.000 - Size 10.000
<empty> - Size 30.000
> I wonder if other users of FFS would find a possibility to identify renamed
or moved files useful.
They do:
[404, Invalid URL: http://sourceforge.net/tracker/?func=detail&aid=2880632&group_id=234430&atid=1093083]
> Most of the time I'm using a stable sort. Rows that are considered
equivalent are not reordered. Therefore all rows that fall into category 2 and
3 are not reordered.
I observe that category 3 (empty entries) are reordered. I understand it does
not behave not as intended.
>Additional note: There is a logical issue when sorting respects both sides.
For example the following cannot be sorted according to both sides...
Why not? It is a situation I described before, the matching files MUST be
displayed in one row, that is clear.
If we sort in descending order by a file size the left hand side:
Size 50.000 - Size 50.000 (file modified, size unchanged)
Size 40.000 - <empty> (file renamed, delete row, right now (v3.6) we have
empty entries on the other side)
<empty> - 40.000 (file renamed, copy a new instance, 40k falls in between 40k
and 20k of the active side)
<empty> - Size 30.000 (file deleted, 30k falls in between 40k and 20k of the
active side)
Size 20.000 - Size 10.000 (file modified, size decreased, the matching row has
a higher priority than a sorting rule of the other side )
Size 10.000 - Size 20.000 (file modified, size increased)
<empty> - Size 4.000 (file deleted, 4k falls after 10k of the active side)
In this scheme the sorting method is the same as it is right now (v3.6) with
the exception of how the empty entries are treated. Currently they go to the
end of the list, in the scheme above they would interleave entries from a
Category 1 (if 1: the row in active side has an empty entry and 2: the sorting
attribute of the file on the other side falls in between of values of the
files on the active side).
regards,
szumu
equivalent are not reordered. Therefore all rows that fall into category 2 and
3 are not reordered.
I observe that category 3 (empty entries) are reordered. I understand it does
not behave not as intended.
>Additional note: There is a logical issue when sorting respects both sides.
For example the following cannot be sorted according to both sides...
Why not? It is a situation I described before, the matching files MUST be
displayed in one row, that is clear.
If we sort in descending order by a file size the left hand side:
Size 50.000 - Size 50.000 (file modified, size unchanged)
Size 40.000 - <empty> (file renamed, delete row, right now (v3.6) we have
empty entries on the other side)
<empty> - 40.000 (file renamed, copy a new instance, 40k falls in between 40k
and 20k of the active side)
<empty> - Size 30.000 (file deleted, 30k falls in between 40k and 20k of the
active side)
Size 20.000 - Size 10.000 (file modified, size decreased, the matching row has
a higher priority than a sorting rule of the other side )
Size 10.000 - Size 20.000 (file modified, size increased)
<empty> - Size 4.000 (file deleted, 4k falls after 10k of the active side)
In this scheme the sorting method is the same as it is right now (v3.6) with
the exception of how the empty entries are treated. Currently they go to the
end of the list, in the scheme above they would interleave entries from a
Category 1 (if 1: the row in active side has an empty entry and 2: the sorting
attribute of the file on the other side falls in between of values of the
files on the active side).
regards,
szumu
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> the matching row has a higher priority
This rule ensures that only the selected column is sorted correctly. But the
corresponding column on the other side still would contain a more or less
unsorted sequence.
Generally I think your proposal as well as the algorithm that is currently
implemented are feasible. But in the end it all boils down to the single
question of whether a user want/accepts "holes" in a sorted sequence. The
answer is dependent on the usecase: If the tool is used to manually find
renamed files by comparing filesize, then a sorting like proposed above would
be required. If on the other hand a user wants to find the largest files from
the source side only, then the way it's implemented right now is the way to
go. At the moment I don't see a way how to fulfill both usecases at the same
time.
This rule ensures that only the selected column is sorted correctly. But the
corresponding column on the other side still would contain a more or less
unsorted sequence.
Generally I think your proposal as well as the algorithm that is currently
implemented are feasible. But in the end it all boils down to the single
question of whether a user want/accepts "holes" in a sorted sequence. The
answer is dependent on the usecase: If the tool is used to manually find
renamed files by comparing filesize, then a sorting like proposed above would
be required. If on the other hand a user wants to find the largest files from
the source side only, then the way it's implemented right now is the way to
go. At the moment I don't see a way how to fulfill both usecases at the same
time.
