[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: dead CVS files, CVS log file equivalent
From: |
graydon hoare |
Subject: |
[Monotone-devel] Re: dead CVS files, CVS log file equivalent |
Date: |
Tue, 20 Apr 2004 13:49:46 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (X11/20040208) |
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