I can confirm that the following features of CVS import flawlessly work:
- binary import (tested with 00-FF FF-00 00FF 01FE ... 7F80 data)
- reimport of a CVS repository with no new files added
Once you add a file to the repository the file is present in all
manifests (regardless of it's visibility within CVS). This results in
different manifests and a copy of the full revision history in a
separate tree.
This relates to a bug reported by Tom (dead revisions are visible again
after import) and a bug filed by Graydon (we throw the first log away,
don't do that) [from memory of course].
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]
------
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)
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).
------
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)
Christof
|
| 
