On Fri, 09 Aug 2013 18:42:59 +0200, Richard Hipp <[email protected]> wrote:
On Fri, Aug 9, 2013 at 12:28 PM, j. van den hoff
<[email protected]>wrote:
so fossil only logs the rename as DELETED plus
and ADDED action w/o keeping track of the rename any more so a diff can
only be done manually by extracting both revisions (pre/post rename)
from
the repo?
Fossil does keeps track of renames. But the current diff logic does not
make use of that information.
Part of the problem arises from syntax. If you type:
fossil diff --from abc --to cde xyz.txt
Are you meaning the diff the file xyz.txt in version abc against whatever
that file is called in version cde. Or do you mean to diff the xyz.txt
in
cde against the equivalent file in abc?
one could decide once and for all which variant is intended.
`hg', e.g., uses your variant 2 (file refers to the `--to' revision,
which intuitively is somewhat better (especially if `--to' is omitted
in which case it ensures that `file' is just the working copy which
the user wants to diff against a former version before the rename.
so that is a non-issue as far as I can see.
As I sit here and ponder the problem, I think I prefer the current
behavior
anyhow. I think the command above should mean to compute the diff
between
file called xyz.txt in the two specified versions, regardless of their
relative ancestry. If you want to diff file xyz.txt in one version
against
file pqr.txt in another version, you should say so. (That is not
something
that the diff command currently supports directly, but it could be
added, I
suppose, and I'd be more inclined to add that than to make the diff
command
magically track file renames through time.)
you are the one who decides this. but I would argue that a diff between
differently named files (not connected by a rename) is not that useful a
feature for the revision control system. on the other hand, a diff across
renames I feel
is _quite_ useful since I'm sure file renaming (including moving files
to different or newly created dirs: I'm not sure whether such a `mv' is any
different from renaming the file itself?) is happening quiet often for one
reason
or other. I try to avoid them but of course they happen and obviously the
user is interested in using the system across the "rename boundaries".
The other part of the problem is that I do most of the implementation for
things like this and I rarely ever rename files in a project, so diffing
between two versions of a file whose name has changed is not something
that
comes up for me very often, and hence is not a priority. You are more
again, you decide that (whether or not important to you). I suspect it's
not the majority view, though. and PR wise the competitors usually make
quite a big point of diff tracking capabilities across renames.
than
welcomed to submit patches if it is a priority for you, though.
would be willing to do that if I were more fluent in C (let alone anything
sql) than I am these days.
so I'm afraid that's not too realistic, unfortunately.
and I have no idea how much work (meaning how complicated) it would be:
you say it's only the diff logic? does that mean
that mostly one "only" would have to resolve the syntax issue (my vote
would go to mimicking `hg' here,
since it is sure the right behavior, especially if only `-r' is specified)
and that than the
required information (and artifacts to pick) would be easy to feed to the
diff?
j.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
