Re: [fossil-users] Problem: Can't get diff against renamed file
On Tue, 29 Apr 2014 19:50:39 +0200, Richard Hipp d...@sqlite.org wrote: File renames are uncommon in Fossil itself. See http://www.fossil-scm.org/fossil/test-rename-list for a complete list of all file renames that have occurred over the entire 6.78-year history of Fossil. Renames in SQLite are similarly scarce ( http://www.sqlite.org/src/test-rename-list). Hence, diffs across renames just a short feedback: I think keeping the `test-rename-list' would be a welcome additional feature (even if rename-aware diff would become a reality). at least it helps to keep track of what renames have happened at some time or other (and thus allows to do the diff across the rename manually if everything else fails). have never been a priority. for fossil in the wild the rating of this might be different, partly. overall I agree that most of the time this is not an issue. but _when_ it is it can be a serious one. I presume reorganizing a modest-size project by moving stuff from one subdir to another could really cause quite a bit of trouble when wanting to diff against old revisions afterwards. The most recent rename (on 2013-12-17) is seen here: http://www.fossil-scm.org/fossil/timeline?n=5c=2013-12-17+22:10:50v http://www.fossil-scm.org/fossil/info/8fab3e3f6ccafdb Notice that on the diff shown on the info page of the check-in, it correctly shows the changes that occurred to the file in parallel with the file rename. However, if you do a diff, it shows the old file being deleted and the new file being added: http://www.fossil-scm.org/fossil/vdiff?from=555c44eb5d9506e7to=8fab3e3f6ccafdb3sbs=1 The latter URL above can be used as a test-case when implementing rename-aware diff. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Wed, Apr 30, 2014 at 11:02 PM, j. van den hoff veedeeh...@googlemail.com wrote: just a short feedback: I think keeping the `test-rename-list' would be a welcome additional feature (even if rename-aware diff would become a reality). at least it helps to keep track of what renames have happened at some time or other (and thus allows to do the diff across the rename manually if everything else fails). +1. For those who haven't seen this (i think the command itself was renamed?): [stephan@host:~/cvs/fossil/cwal]$ f help test-name-changes Usage: f test-name-changes [--debug] VERSION1 VERSION2 Show all filename changes that occur going from VERSION1 to VERSION2 [stephan@host:~/cvs/fossil/cwal]$ f test-name-changes rid:1 tip -- Changes for (1) rid:1 - (3687) tip [th1ish/20.th1ish] - [th1ish/unit/000-020.th1ish] [th1ish/19.th1ish] - [th1ish/unit/000-019.th1ish] [s1/th1ish.c] - [th1ish/th1ish.c] [cwal_list.h] - [include/wh/cwal/cwal_list.h] (28 files in total for this repo, where i once moved 22 test scripts.) for fossil in the wild the rating of this might be different, partly. overall I agree that most of the time this is not an issue. but _when_ it is it can be a serious one. i'd say annoying rather than serious, since the HTML UI offers an option. Agreed: when it's useful, it's really useful. But it's just not all that often useful :/. I presume reorganizing a modest-size project by moving stuff from one subdir to another could really cause quite a bit of trouble when wanting to diff against old revisions afterwards. presume implies that you've never had a real problem with it ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Wed, Apr 30, 2014 at 11:09 PM, Stephan Beal sgb...@googlemail.comwrote: For those who haven't seen this (i think the command itself was renamed?): Sorry for the confusion: Richard referred to a WWW page for doing this, not a CLI command (which is also useful but doesn't currently show all the same info). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Wed, 30 Apr 2014 23:09:45 +0200, Stephan Beal sgb...@googlemail.com wrote: On Wed, Apr 30, 2014 at 11:02 PM, j. van den hoff veedeeh...@googlemail.com wrote: just a short feedback: I think keeping the `test-rename-list' would be a welcome additional feature (even if rename-aware diff would become a reality). at least it helps to keep track of what renames have happened at some time or other (and thus allows to do the diff across the rename manually if everything else fails). +1. For those who haven't seen this (i think the command itself was renamed?): [stephan@host:~/cvs/fossil/cwal]$ f help test-name-changes Usage: f test-name-changes [--debug] VERSION1 VERSION2 Show all filename changes that occur going from VERSION1 to VERSION2 [stephan@host:~/cvs/fossil/cwal]$ f test-name-changes rid:1 tip -- Changes for (1) rid:1 - (3687) tip [th1ish/20.th1ish] - [th1ish/unit/000-020.th1ish] [th1ish/19.th1ish] - [th1ish/unit/000-019.th1ish] [s1/th1ish.c] - [th1ish/th1ish.c] [cwal_list.h] - [include/wh/cwal/cwal_list.h] (28 files in total for this repo, where i once moved 22 test scripts.) for fossil in the wild the rating of this might be different, partly. overall I agree that most of the time this is not an issue. but _when_ it is it can be a serious one. i'd say annoying rather than serious, since the HTML UI offers an yes, that's more to the point (you are the native speaker after all) option. Agreed: when it's useful, it's really useful. But it's just not all that often useful :/. sometimes really useful still translates to desirable (not just nice to have) for me. principally, the asymmetry in the degree of handling of renames across different commands should not be there. `diff' across a rename simply does not answer the question the user actually is asking at the point I'd say. whether someone sacrifices his time to actually implement full rename support (including diff, finfo (no history for file...), timeline etc.) is a different question for sure. I presume reorganizing a modest-size project by moving stuff from one subdir to another could really cause quite a bit of trouble when wanting to diff against old revisions afterwards. presume implies that you've never had a real problem with it ;). not on that scale, but quite a few times to some extent. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Wed, 30 Apr 2014 23:12:45 +0200, Stephan Beal sgb...@googlemail.com wrote: On Wed, Apr 30, 2014 at 11:09 PM, Stephan Beal sgb...@googlemail.comwrote: For those who haven't seen this (i think the command itself was renamed?): Sorry for the confusion: Richard referred to a WWW page for doing this, not a CLI command (which is also useful but doesn't currently show all the same info). actually, the CLI should (and now could?) show the same, complete info in my view. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Wed, Apr 30, 2014 at 11:34 PM, j. van den hoff veedeeh...@googlemail.com wrote: On Wed, 30 Apr 2014 23:12:45 +0200, Stephan Beal sgb...@googlemail.com wrote: Sorry for the confusion: Richard referred to a WWW page for doing this, not a CLI command (which is also useful but doesn't currently show all the same info). actually, the CLI should (and now could?) show the same, complete info in my view. Oh, it will the next time i need it ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
But there are some problems (This is fossil version 1.29 [003db810a2] 2014-04-30 18:02:45 UTC): fossil test-name-changes -R \db\some.fossil prev trunk Assertion failed: e0, file ..\src\bag.c, line 122 Stephan Beal wrote: On Wed, Apr 30, 2014 at 11:02 PM, j. van den hoff veedeeh...@googlemail.com wrote: just a short feedback: I think keeping the `test-rename-list' would be a welcome additional feature (even if rename-aware diff would become a reality). at least it helps to keep track of what renames have happened at some time or other (and thus allows to do the diff across the rename manually if everything else fails). +1. For those who haven't seen this (i think the command itself was renamed?): [stephan@host:~/cvs/fossil/cwal]$ f help test-name-changes Usage: f test-name-changes [--debug] VERSION1 VERSION2 Show all filename changes that occur going from VERSION1 to VERSION2 [stephan@host:~/cvs/fossil/cwal]$ f test-name-changes rid:1 tip -- Changes for (1) rid:1 - (3687) tip [th1ish/20.th1ish] - [th1ish/unit/000-020.th1ish] [th1ish/19.th1ish] - [th1ish/unit/000-019.th1ish] [s1/th1ish.c] - [th1ish/th1ish.c] [cwal_list.h] - [include/wh/cwal/cwal_list.h] (28 files in total for this repo, where i once moved 22 test scripts.) I presume reorganizing a modest-size project by moving stuff from one subdir to another could really cause quite a bit of trouble when wanting to diff against old revisions afterwards. presume implies that you've never had a real problem with it ;). It may also mean he never dared to try fearing the consequences... We all need to re-organize our projects from time to time and this naming problem makes it a no-no! By the way, the frequency of FOSSIL or SQLITE project filename changes are NOT a measure by which to estimate the need for this feature. Unless FOSSIL was only meant to be used for these two specific projects! Renaming or moving around files is a quite common operation in most projects as they grow more complex. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Wed, Apr 30, 2014 at 11:36 PM, to...@acm.org wrote: But there are some problems (This is fossil version 1.29 [003db810a2] 2014-04-30 18:02:45 UTC): fossil test-name-changes -R \db\some.fossil prev trunk Assertion failed: e0, file ..\src\bag.c, line 122 Reproducible here. i'll take a look. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Wed, Apr 30, 2014 at 11:38 PM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Apr 30, 2014 at 11:36 PM, to...@acm.org wrote: But there are some problems (This is fossil version 1.29 [003db810a2] 2014-04-30 18:02:45 UTC): fossil test-name-changes -R \db\some.fossil prev trunk Assertion failed: e0, file ..\src\bag.c, line 122 Reproducible here. i'll take a look. Solved. The problem is that 'prev' does not resolve (has no meaning) when no checkout is opened, and -R suppresses the opening of a checkout. [stephan@host:~/cvs/fossil/cwal]$ fossil test-name-changes -R ../cwal.fsl prev trunk Invalid 'from' RID: 0 That's not _much_ better, but the place at which this failure is recognized is a bit downstream of where the symbolic lookup actually fails (and it gets a 0 as a result of that lookup failure). Now fixed in the trunk. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Tue, Apr 29, 2014 at 5:41 PM, Tony Papadimitriou to...@acm.org wrote: If I rename a file (both on disk and with FOSSIL REN command), and then try to do a [G]DIFF command –FROM a date where the file had the old name, I get the message that the file does not exist in that checkin. So, once I rename a file I lose the connection to all its history and the changes made to it? The history is not lost, but gdiff cannot deal with it directly because (as it says) it does not [any longer] know about the old name (where any longer is always based on the current checkout version). You can probably get it to work by using gdiff without any filenames. You'll see the whole diff, including other files. You might also try... i thought we had a --glob option for diff/gdiff, but apparently we don't. Added to the TODO list. I understand it now has a different name, but it seems to me that part of keeping history of changes is to also know that the name changed, so if I want to get the diff from version A to version B it should do so even if the file has changed names between the two versions (because FOSSIL knows – or should know -- about this change of name). Everything's there and you can follow the rename (and the diff, IIRC) via the HTML UI. I also suspect (but haven’t tested to see if it is so) that if the old checkin happened to have a file with the same name as the current version’s renamed one (but the old version’s was at some point either renamed or deleted), FOSSIL would try to give me the DIFF between two completely unrelated files. Correct, because fossil's only way of knowing the identity of a file is its name. If you take my name, everyone will think you're me. Nothing i can do about that. The SHA1 unique identifies the version of the content, but the name gives us a place under which to organize that. That just doesn’t seem correct behavior. Comments? Of course it is. Fossil knows nothing about the semantics of the contents of the file you replaced, except where it has to for proper operation (e.g. it expects text files to have newlines so that the diff view can work, and long files with no newlines are assumed to be binary). Maybe you removed the file, realized you needed it again, and re-added it (with different content). Fossil can't know the intention there. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Tue, 29 Apr 2014 17:48:10 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Tue, Apr 29, 2014 at 5:41 PM, Tony Papadimitriou to...@acm.org
wrote:
If I rename a file (both on disk and with FOSSIL REN command), and
then
try to do a [G]DIFF command –FROM a date where the file had the old
name, I
get the message that the file does not exist in that checkin.
So, once I rename a file I lose the connection to all its history and
the
changes made to it?
The history is not lost, but gdiff cannot deal with it directly because
(as
it says) it does not [any longer] know about the old name (where any
longer is always based on the current checkout version). You can
probably
get it to work by using gdiff without any filenames. You'll see the whole
diff, including other files. You might also try... i thought we had a
--glob option for diff/gdiff, but apparently we don't. Added to the TODO
list.
I understand it now has a different name, but it seems to me that part
of keeping history of changes is to also know that the name changed, so
if
I want to get the diff from version A to version B it should do so even
if
the file has changed names between the two versions (because FOSSIL
knows –
or should know -- about this change of name).
Everything's there and you can follow the rename (and the diff, IIRC) via
the HTML UI.
I also suspect (but haven’t tested to see if it is so) that if the old
checkin happened to have a file with the same name as the current
version’s
renamed one (but the old version’s was at some point either renamed or
deleted), FOSSIL would try to give me the DIFF between two completely
unrelated files.
Correct, because fossil's only way of knowing the identity of a file is
its
name. If you take my name, everyone will think you're me. Nothing i can
do
about that. The SHA1 unique identifies the version of the content, but
the
name gives us a place under which to organize that.
I understand that that's the current state of affairs. I don't understand
whether this could/should not be changed.
I of course don't know the inner workings of fossil but I know that a
`renaming' checkin puts the rename info into the
manifest of the checkin, right?
would it not be possible to propagate renaming information through all
future checkins including the respective file?
if such (possibly chain of multiple) renames are available in the most
recent checkin of a file, it _should_ be possible
to use
fossil diff -r{rev_before_rename_from_A_to_B} B
or am I missing some fundamental reason why this would'nt work? I
presume(...) it currently does not work since fossil
just looks up file B in {rev_before_rename_from_A_to_B} (and does not find
it there or, even worse, another file having had
the same name at that time) instead of following the strategy OK, file
B's current state in the repo is such and such and
it was renamed in the past during checkin/at time so and so, at time of
checkin of {rev_before_rename_from_A_to_B} its name was A
so show the diff between file A from that revision and the current B
accordingly. wouldn,t this work (if it were (and could be) implemented)?
from a user perspective at least it would be very reasonable to get the
diff across renames.
j.
That just doesn’t seem correct behavior. Comments?
Of course it is. Fossil knows nothing about the semantics of the contents
of the file you replaced, except where it has to for proper operation
(e.g.
it expects text files to have newlines so that the diff view can work,
and
long files with no newlines are assumed to be binary). Maybe you removed
the file, realized you needed it again, and re-added it (with different
content). Fossil can't know the intention there.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
Stephan Beal wrote: Correct, because fossil's only way of knowing the identity of a file is its name. If you take my name, everyone will think you're me. Nothing i can do about that. The SHA1 unique identifies the version of the content, but the name gives us a place under which to organize that. I see the simplistic approach. On the other hand, if I decided to change my name at some point, the authorities should be able to trace my current name to my birth name, to figure out who I am, and my ‘criminal’ record should not disappear!!! Anyway, (as a future enhancement, perhaps) if FOSSIL knows in its trail of changes from version A to version B that a file was renamed it should be able to figure out and locate the correct file (by name) in the old version and do a correct DIFF, while giving the “doesn’t exist” error if the file was not yet introduced (by ADD or ADDR). And, obviously, FOSSIL does know, as it can be seen from the UI (“Name change from ... to ...”). Of course that would mean that to find what filename to compare it with, it should do a walk-thru of all intermediate checkins from A to B, and not just look at the two versions as two independent checkins (which I suspect is what happens now) without regard to what happened in between (and I mean only in relation to name changes, of course, not their contents). Thanks.___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Tue, Apr 29, 2014 at 6:18 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
I understand that that's the current state of affairs. I don't understand
whether this could/should not be changed.
Patches welcomed :)
I of course don't know the inner workings of fossil but I know that a
`renaming' checkin puts the rename info into the
manifest of the checkin, right?
That's the problem: it's in THAT checkin, and only that checkin. The next
one no longer knows about the rename. In order to figure it out, we have to
search through historical data, which can get slow/expensive to do (and
would only be to cover this specific corner case).
would it not be possible to propagate renaming information through all
future checkins including the respective file?
To what end? So that the diff command knows how to handle a rename
gracefully on the CLI? That seems like overkill. It would also require an
incompatible change to the underlying data format (which is effectively
immutable, having changed only a small number of times in its existence).
It would require adding an ever-growing amount of data to all future
commits to track renames which happened arbitrarily far back in the past.
The db side _does_ track this information, but the underlying metadata does
not - it records the one-time change and the db then links the versions
together in a way which allows traversal over them (which, in turn, allows
us to diff them).
if such (possibly chain of multiple) renames are available in the most
recent checkin of a file, it _should_ be possible
to use
fossil diff -r{rev_before_rename_from_A_to_B} B
The data to do it is there. Calculating it is not trivial, though.
or am I missing some fundamental reason why this would'nt work? I
presume(...) it currently does not work since fossil
just looks up file B in {rev_before_rename_from_A_to_B} (and does not
find it there or, even worse, another file having had
the same name at that time) instead of following the strategy OK, file
B's current state in the repo is such and such and
it was renamed in the past during checkin/at time so and so, at time of
checkin of {rev_before_rename_from_A_to_B} its name was A
so show the diff between file A from that revision and the current B
accordingly. wouldn,t this work (if it were (and could be) implemented)?
Fossil cannot _possibly_ know that a replaced file now has different
semantics. NO file-tracking system can know that. Your filesystem doens't
know that, either. If it has two files with the same name, they're the same
file. Archival/backup systems - same thing. This is not a limitation of the
filesystems, but a unrealistic expectation that it could somehow know that
two files, with the same name, existing at different points in time, are
_not_ related. Even a human being would assume they are related unless they
just happen to know the history of that file (which most people don't).
Sidebar: try opening two files in Microsoft Excel with the same base name:
C:\one.xls and C:\TEMP\one.xls. Excel sees them as the same file (same
name) and refuses to open the second one!
from a user perspective at least it would be very reasonable to get the
diff across renames.
Patches are welcomed!
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Tue, Apr 29, 2014 at 6:18 PM, Tony Papadimitriou to...@acm.org wrote: I see the simplistic approach. On the other hand, if I decided to change my name at some point, the authorities should be able to trace my current name to my birth name, to figure out who I am, and my ‘criminal’ record should not disappear!!! They can, but the authorities will use the HTML UI to do it because the feature can be found there. Anyway, (as a future enhancement, perhaps) if FOSSIL knows in its trail of changes from version A to version B that a file was renamed it should be able to figure out and locate the correct file (by name) in the old version and do a correct DIFF, while giving the “doesn’t exist” error if the file was not yet introduced (by ADD or ADDR). And, obviously, FOSSIL does know, as it can be seen from the UI (“Name change from ... to ...”). See my previous response to Joerg for more details on that. Of course that would mean that to find what filename to compare it with, it should do a walk-thru of all intermediate checkins from A to B, and not just look at the two versions as two independent checkins (which I suspect is what happens now) without regard to what happened in between (and I mean only in relation to name changes, of course, not their contents). Right. We would need to walk each version between the two, remember and arbitrary number of renames, and then refer to/process them properly when we generate the diff from (only) the first and last version. It would increase the computational cost of a diff arbitrarily. For example: fossil diff --from rid:1 --to trunk a diff of the first and last checkins is just as fast as a diff for any other two checkins with the same amount of content changes. Calculating the renames for the ... 6942 checked-in versions between the first (rid:1) and trunk would take... a good long while. It's not a cost which the diff command should pay, IMO. Maybe an extra --track-renames arg, but that adds a ton of complication for what i personally consider to be very much not worth the effort. Pop up the GUI or use one of the libfossil CLI tools to do it: [stephan@host:~/cvs/fossil/libfossil]$ f-ls -v rid:37 | grep fsl_appendf fe6db9258632 - fsl_appendf.c bc4949627209 - include/fossil/fsl_appendf.h [stephan@host:~/cvs/fossil/libfossil]$ f-ls -v trunk | grep fsl_appendf 06a9ce020773 - src/fsl_appendf.c [stephan@host:~/cvs/fossil/libfossil]$ f-adiff fe6db9258632 06a9ce020773 | less -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
The infrastructure exists for Fossil to recognize name changes: http://www.fossil-scm.org/fossil/artifact/59e624a3955?ln=353-376 That infrastructure is currently used for the update and merge commands. But it has not yet been incorporated into the diff command. On Tue, Apr 29, 2014 at 11:41 AM, Tony Papadimitriou to...@acm.org wrote: If I rename a file (both on disk and with FOSSIL REN command), and then try to do a [G]DIFF command –FROM a date where the file had the old name, I get the message that the file does not exist in that checkin. So, once I rename a file I lose the connection to all its history and the changes made to it? I understand it now has a different name, but it seems to me that part of keeping history of changes is to also know that the name changed, so if I want to get the diff from version A to version B it should do so even if the file has changed names between the two versions (because FOSSIL knows – or should know -- about this change of name). I also suspect (but haven’t tested to see if it is so) that if the old checkin happened to have a file with the same name as the current version’s renamed one (but the old version’s was at some point either renamed or deleted), FOSSIL would try to give me the DIFF between two completely unrelated files. That just doesn’t seem correct behavior. Comments? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Tue, 29 Apr 2014 18:28:06 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Tue, Apr 29, 2014 at 6:18 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
I understand that that's the current state of affairs. I don't
understand
whether this could/should not be changed.
Patches welcomed :)
sure but it seems quite obvious that only a very few people right now would
be able to do that. not me anyway.
I of course don't know the inner workings of fossil but I know that a
`renaming' checkin puts the rename info into the
manifest of the checkin, right?
That's the problem: it's in THAT checkin, and only that checkin. The next
one no longer knows about the rename. In order to figure it out, we have
to
search through historical data, which can get slow/expensive to do (and
would only be to cover this specific corner case).
would it not be possible to propagate renaming information through all
future checkins including the respective file?
To what end? So that the diff command knows how to handle a rename
gracefully on the CLI? That seems like overkill. It would also require an
I wouldn't think so. rather, it seems that many users prefer the CLI (me,
too) and that being
able to do a diff between versions is _the_ most important feature of a
VCS (apart from simply
logging all of them, of course).
incompatible change to the underlying data format (which is effectively
immutable, having changed only a small number of times in its existence).
but it did at times, so the question is only whether it's worth it. also,
I'm not sure how
massive the change to the data format would need to be. would it harm to
just add another
field to the manifest containing the relevant information (e.g. all the
checkins where a certain file was renamed or similar) which
if absent would simply mean information not available?
It would require adding an ever-growing amount of data to all future
commits to track renames which happened arbitrarily far back in the past.
how big of an overhead could that possibly be in a realistic use case?
The db side _does_ track this information, but the underlying metadata
does
not - it records the one-time change and the db then links the versions
together in a way which allows traversal over them (which, in turn,
allows
us to diff them).
if such (possibly chain of multiple) renames are available in the most
recent checkin of a file, it _should_ be possible
to use
fossil diff -r{rev_before_rename_from_A_to_B} B
The data to do it is there. Calculating it is not trivial, though.
or am I missing some fundamental reason why this would'nt work? I
presume(...) it currently does not work since fossil
just looks up file B in {rev_before_rename_from_A_to_B} (and does not
find it there or, even worse, another file having had
the same name at that time) instead of following the strategy OK, file
B's current state in the repo is such and such and
it was renamed in the past during checkin/at time so and so, at time of
checkin of {rev_before_rename_from_A_to_B} its name was A
so show the diff between file A from that revision and the current B
accordingly. wouldn,t this work (if it were (and could be)
implemented)?
Fossil cannot _possibly_ know that a replaced file now has different
semantics. NO file-tracking system can know that. Your filesystem doens't
know that, either. If it has two files with the same name, they're the
same
file. Archival/backup systems - same thing. This is not a limitation of
the
filesystems, but a unrealistic expectation that it could somehow know
that
two files, with the same name, existing at different points in time, are
_not_ related. Even a human being would assume they are related unless
they
just happen to know the history of that file (which most people don't).
Sidebar: try opening two files in Microsoft Excel with the same base
name:
C:\one.xls and C:\TEMP\one.xls. Excel sees them as the same file (same
name) and refuses to open the second one!
from a user perspective at least it would be very reasonable to get the
diff across renames.
Patches are welcomed!
back to field no. 1 ;-)
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
another related thing: after fossil ren A B I get the message RENAME A B when then doing mv A B as well, `fossil changes' (IIRC or was it `status' as well?) tells me RENAMED A B #note the change RENAME - RENAMED both of which is fine. after checkin, however, fossil timeline -showfiles tells me only DELETED A for the renaming checkin. would it not be more helpful/correct to issue the `RENAMED A B' message at this place, too? On Tue, 29 Apr 2014 18:42:05 +0200, j. van den hoff veedeeh...@googlemail.com wrote: On Tue, 29 Apr 2014 18:36:17 +0200, Richard Hipp d...@sqlite.org wrote: The infrastructure exists for Fossil to recognize name changes: http://www.fossil-scm.org/fossil/artifact/59e624a3955?ln=353-376 That infrastructure is currently used for the update and merge commands. But it has not yet been incorporated into the diff command. that is really good news. predictable question from end user: is there any chance to see it incorporated for `diff' as well in finite time? I was bitten by the absence of this feature a few times which effectively has let to a state where I try to avoid (otherwise desirable) renames just to keep out of subsequent trouble during diffs. I really would appreciate it if this were fixed. On Tue, Apr 29, 2014 at 11:41 AM, Tony Papadimitriou to...@acm.org wrote: If I rename a file (both on disk and with FOSSIL REN command), and then try to do a [G]DIFF command –FROM a date where the file had the old name, I get the message that the file does not exist in that checkin. So, once I rename a file I lose the connection to all its history and the changes made to it? I understand it now has a different name, but it seems to me that part of keeping history of changes is to also know that the name changed, so if I want to get the diff from version A to version B it should do so even if the file has changed names between the two versions (because FOSSIL knows – or should know -- about this change of name). I also suspect (but haven’t tested to see if it is so) that if the old checkin happened to have a file with the same name as the current version’s renamed one (but the old version’s was at some point either renamed or deleted), FOSSIL would try to give me the DIFF between two completely unrelated files. That just doesn’t seem correct behavior. Comments? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On 4/29/2014 11:36 AM, Richard Hipp wrote: The infrastructure exists for Fossil to recognize name changes: http://www.fossil-scm.org/fossil/artifact/59e624a3955?ln=353-376 That infrastructure is currently used for the update and merge commands. But it has not yet been incorporated into the diff command. Or Stash, I might add. http://www.fossil-scm.org/index.html/tktview?name=99bca9b4d8 -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
File renames are uncommon in Fossil itself. See http://www.fossil-scm.org/fossil/test-rename-list for a complete list of all file renames that have occurred over the entire 6.78-year history of Fossil. Renames in SQLite are similarly scarce ( http://www.sqlite.org/src/test-rename-list). Hence, diffs across renames have never been a priority. The most recent rename (on 2013-12-17) is seen here: http://www.fossil-scm.org/fossil/timeline?n=5c=2013-12-17+22:10:50v http://www.fossil-scm.org/fossil/info/8fab3e3f6ccafdb Notice that on the diff shown on the info page of the check-in, it correctly shows the changes that occurred to the file in parallel with the file rename. However, if you do a diff, it shows the old file being deleted and the new file being added: http://www.fossil-scm.org/fossil/vdiff?from=555c44eb5d9506e7to=8fab3e3f6ccafdb3sbs=1 The latter URL above can be used as a test-case when implementing rename-aware diff. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Problem: Can't get diff against renamed file
On Tue, 29 Apr 2014 19:50:39 +0200, Richard Hipp d...@sqlite.org wrote: File renames are uncommon in Fossil itself. See http://www.fossil-scm.org/fossil/test-rename-list for a complete list of all file renames that have occurred over the entire 6.78-year history of Fossil. Renames in SQLite are similarly scarce ( http://www.sqlite.org/src/test-rename-list). Hence, diffs across renames have never been a priority. The most recent rename (on 2013-12-17) is seen here: http://www.fossil-scm.org/fossil/timeline?n=5c=2013-12-17+22:10:50v http://www.fossil-scm.org/fossil/info/8fab3e3f6ccafdb Notice that on the diff shown on the info page of the check-in, it correctly shows the changes that occurred to the file in parallel with the file rename. However, if you do a diff, it shows the old file being deleted and the new file being added: http://www.fossil-scm.org/fossil/vdiff?from=555c44eb5d9506e7to=8fab3e3f6ccafdb3sbs=1 The latter URL above can be used as a test-case when implementing rename-aware diff. would this be easy or complicated to do? anybody out there who would be willing and able to take this over? I'm quite pessimistic whether I could do this (no C programming for many years)... -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
