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.com>wrote:
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
