[Monotone-devel] Re: dead CVS files, CVS log file equivalent

[graydon hoare]

Christof Petig wrote:

> I want to fix this bug fast, so I ask for a _short_ suggestion by 
> Graydon on how to implement a file visibility feature. [I did not yet 
> look too deeply into the current implementation]

I'd love to see a fix for this. here is a guess at the work:

 - modify the rcs_delta structure in rcs_file.hh to contain "state"
 - copy the "state" value in rcs_file.cc:parser::parse_deltas to this
   field in the structure.
 - insert boolean parent_live_p and child_live_p fields in the
   cvs_file_edge structure, in rcs_import.cc
 - in cvs_history::note_file_edge, indicate whether the parent and
   child of the edge is considered in live or dead state
 - in build_child_state and build_parent_state -- which are building
   manifests by analyzing file edges -- make sure to remove any files
   which changed from live to dead and add any files which changed from
   dead to live
 - make sure the cvs_tree_walker collapses Attic/foo,v -> foo,v so you
   get the filename right

hopefully that will be close to all you need. hope hope.

> Apart from that my most loved command (cvs log file) does not work any 
> longer with monotone. This clearly sucks since it is very pleasant to 
> get the revision history of one singular file.
>
> My current implementation proposal would be:
> - get the active manifest value from the MT/manifest file
> - walk up the tree like monotone log does but only report manifests 
> which change the sha1 value (or presence) of this file (by creating the 
> manifest)

yeah. this is roughtly the approach I would take too. it might be worth 
abstracting out the "walk up a manifest graph in a sensible order 
calling a callback" activity into its own class. I suspect we'll use it 
more often as time goes on.

we also need a general -- not too deep, just systematic -- reworking of 
the command set to differentiate between files and manifests, and permit 
file-oriented variants of commands. a lot of people have asked for 
file-oriented commands (committing a specific group of files, showing 
their history, showing their diffs, etc.)

> This way the information should be similar to what cvs gives/gave. I'm 
> still not clear about how to represent branches (which are much more 
> likely in monotone) and merge points. Perhaps output in chronological 
> order is best (cvs gives them in an ugly order: chronological but 
> different branches at the bottom).

I'm not sure either. I think I currently do it as breadth-first reverse 
ancestry. there's arguments either way. I'd be happy with chronological 
too, but it might be a bit more work to construct that view.

> Another idea might be an inverse log function (future) which shows which 
>  revisions derive from the current one (interesting tool to follow 
> commits without updating/mergeing yet)

yes, I'd actually like a general "explain" command which shows you what 
it *would* do if it tried a merge or update (a la cvs -n). but "future" 
is different -- log format browsing -- and sounds good too.

no objections, I just lack the time to do all this.

-graydon