On 09/23/17 11:48, John P. Rouillard wrote:
In message <a3b39e7c-3cf2-41c6-71a4-1beabbe64...@gmail.com>,
Andy Goth writes:
On 09/23/17 10:18, John P. Rouillard wrote:
I am trying to find out when a line disappeared from a file.
I've long wanted a reverse annotate command. Rather than show when each
line was most recently modified or added, it would show when each line
is next modified or removed.
I haven't taken any steps toward implementation because this will be
harder to use (certainly harder to implement) than normal annotation.
Annotate works as well as it does because each revision has only one
primary predecessor, so there's no ambiguity. Reverse annotate won't
magically know the intended "next" version with which to compare. My
best guess at how to handle this is to ask for a target version, and the
path from the current version to the target version is the one along
which changes are examined.
That sounds workable. Similar to diff between two revisions.
Good observation. The diff page could be used as a springboard to
request a reverse annotation. I wanted to avoid requiring the user to
type or paste in check-in IDs.
Is "Reverse Annotate" the right name? On the diff page, this would go
in the list of command links alongside "Invert", "Patch", "Path",
"Side-by-Side Diff", and "Unified Diff".
Like traditional annotation, reverse annotation would show the selected
version of the file, with a check-in identifier on each line. Unlike
traditional annotation, the check-in identifiers would all be future
revisions, showing the *next* time the line is touched in any way.
In this case, the "selected version" would be the diff "from" version,
typically the oldest version.
I guess this would make a double-reverse annotation possible too, should
the user pick the diff versions backwards, from new to old. Going this
direction, a line would be regarded as being deleted because the new
revision has it and the old revision does not. The difference between
this and traditional annotation is it gives finer control over which
predecessor to examine, if the "to" version is on an old branch which
wound up being merged into a branch that contributed to the "from" version.
perforce annotate -a sounds interesting.
"All lines, including deleted lines and lines no longer present at the
head revision, are included. Each line includes a starting and ending
revision."
https://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_annotate.html
Though I suspect it could result in an extremely messy report should the
lines be reorganized multiple times.
It looks like it figures out for each line in the file what line was
at that location in a prior revision. You can specify a range of
revisions as well (not just a -N count). So:
p4 annotate -a myfile@23,40
would just show the lines between the two revisions (@ is a way of
specifying a revision range for a file). You can also do:
myfile@>2017/09/03
to get all lines in revisions created since Sept 3 2017 (@> means the
value is a starting point).
At least in the web interface, Fossil directory listings have the option
of showing the union of all check-ins, i.e. the name of every file that
ever existed, on any branch whatsoever. This the closest analogy I can
think of. If the directory listing could instead be made to show all
filenames that exist either in a current version or any direct
predecessor, up to some optional limit, would that be like what Perforce
annotate -a does?
Also this brings up an interesting point. None of annotate, blame or
praise support specifying the revision of the file. I would think
being able to annotate a previous version of the file would be useful.
You're right, and that does seem useful. Not only that, but the
functionality is available in the web interface, so why not the command
line interface?
annotate_cmd() in diff.c is hard-coded to only work with the current
checkout version. Also, it can't be used outside of a checkout the same
way cat and other commands can when given the -R option.
As far as I can tell, here's the main part that has to change:
https://fossil-scm.org/index.html/artifact?ln=2541-2548&name=d7dd6b9c57ceff7a
Here's the analogous code in the web interface:
https://fossil-scm.org/index.html/artifact?ln=2545&name=d7dd6b9c57ceff7a
Quite a bit simpler, huh? The command line and web interfaces take
totally different approaches to identifying which version to work with.
The web interface simply asks the user, whereas the command line
interface seems to take the long way around. If I'm reading this code
correctly, it finds both the current check-in and the check-in that most
recently modified the file, then uses these two values separately.
Why not make the command line interface code more closely match the web
interface code? Let the annotate command accept a -r option to override
the current check in for the value of mid, then proceed the same as the
web interface code.
fossil --checkin _revision_ _filename_ | grep "option name"
Assuming you meant to have a "cat" in there somewhere. Also I was
unaware the -r option could be spelled out as -checkin.
Actually meant diff in there.
fossil diff --checkin _revision_ _filename_ | grep "option name"
so I can see what lines changed in that revision compared to the
previous revision for the file.
I suppose that will work, possibly faster even, but I was just thinking
of checking whether any given version had the line or not because I had
in mind making the script as simple as possible.
--
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
