Re: [Monotone-devel] File log command-line UI thoughts

[graydon hoare]

Kevin Smith <address@hidden> writes:

> I think it's going to be harder than I thought. If I understand things
> correctly, monotone doesn't "track" file changes. That is, it only
> tracks tree changes, of which file changes happen to be a part.

correct. 

> So, given a file id, I can't ask for the "author" or "date" cert,
> because there aren't any.

well, there might be, but usually not. you can add any certs you like,
but monotone doesn't normally put certs on files.

> So the only way to show a file's history is by walking back through
> manifests, watching for changes to the file in question.

pretty much, yup.

> But we might have a manifest merge (which appears to me as a fork,
> since I'm moving backward in time). The file in question might be
> different in the two ancestors, or it could be the same in both. I'm
> not sure whether to stop there, or keep going, possibly running into
> an n-way "fork" (where multiple different versions of this file may
> have been merged), or possible in a diamond.

yup. that's what I meant by saying that "log" prints the frontier
breadth first. it has a set of nodes, the frontier, which represent
*all* possible ancestors of a given depth. at each step, it prints all
the logs attached to those (in, I think alphabetical order of SHA1 :)
then advances them all up the graph 1 step. it's crude, but it makes
for a nice read. I think that's the real test: "log" should produce
something a human actually wants to read.

>    flog <file-id>
> 
> it would have to be:
> 
>    flog <filename> <manifest-id>
> 
> If manifest-id is omitted, the workspace version would be used. But we
> have to work within the context of a manifest.

oh.. perhaps. you could let it accept plain file ids as well, and try
to search backwards until you find a file which matches the id or hit
the root of history. might have a problem if you hit 2 files with the
same id, of course. 

(also, you might want to infer a head from branch name if there's no
 working copy and no manifest id)

some of the incremental graph walking stuff I recently wrote for
addtree might help speed this up, but I need to alter it a bit
anyways.  it's not entirely sensible right now. try implementing the
command the "natural" way, as an introductory exercize.

> And I thought this feature would be easy.

alas, compared to most this is an easy feature.

but don't worry if it feels hard. they'll feel easier the more time
you spend up to your eyeballs in the code. half the problem is just
you getting used to the internal organization and concept model.

> Am I understanding things correctly?

you seem to have captured it, yes. though as njs points out, I think
it's utterly hilarious to have a version control system which has a
"flog" command in it :)

-graydon