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
