Re: Detecting junk "file ... was added on ..." revisions

Greg Ward wrote:
> I'm investigating why my converted Mercurial repo has a number of
> changesets that look like
> 
>   changeset:   15014:b5e07bb410b8
>   branch:      PACS-3-7-2
>   parent:      14998:d99ab19444c4
>   user:        xxxxxxxxx
>   date:        Fri Aug 14 10:01:02 2009 -0400
>   summary:     file Age.java was added on branch PACS-3-7-2 on
> 2009-08-14 14:02:21 +0000
> 
> Obviously, these are junk revisions that should not be converted.
> I've found the code in CVSFileItems that tries to exclude them and I
> can see *part* of what's going wrong.  Specifically,
> _initial_branch_delete_unneeded() is receiving a lod_items object that
> does not appear to be in the correct state yet:
> 
>   (Pdb) import pprint; pprint.pprint(vars(lod_items))
>   {'cvs_branch': None,
>    'cvs_branches': [],
>    'cvs_revisions': [CVSRevisionNoop(Age.java:1.1.4.1<f>),
>                      CVSRevisionAdd(Age.java:1.1.4.2<10>),
>                      CVSRevisionChange(Age.java:1.1.4.3<11>)],
>    'cvs_tags': [],
>    'lod': PACS-3-7-2<5>}
> 
> Good:
>   * lod_items.lod is set to the right value
>   * lod_items.cvs_revisions includes all the CVS revisions of Age.java
> on PACS-3-7-2, including the junk revision 1.1.4.1
> 
> Bad (I think):
>   * lod_items.lod is a Symbol, not a Branch (even though PACS-3-7-2 is
> unquestionably a CVS branch)

This is normal.  Symbols are not converted into Branches/Tags until
FilterSymbolsPass.

>   * lod_items.cvs_branch is unset (presumably related to the former point)

This is the unexpected situation.  (But it is not related to the former
point.)  Normally this attribute should store the CVSBranch item
associated with the creation of the branch (in this case branch 1.1.4).
 This item should *always* exist after the CVS file is parsed, because
in this file PACS-3-7-2 is definitely a branch tag.

> Because lod_items.cvs_branch is unset,
> _initial_branch_delete_unneeded() quickly bails and we lose the
> opportunity to drop this junk revision.  ;-(
> 
> Any clue what's going on?  When is that 'lod' object supposed to
> change from a Symbol to a Branch?

Symbols are transformed to Branches/Tags in FilterSymbolsPass.

I assume that CVSFileItems.remove_unneeded_deletes() from
_ProjectDataCollector._process_cvs_file_items() (which is called before
CVSFileItems.remove_initial_branch_deletes()) has already altered the
CVSFileItems contents.  Likely the assumption of the following comment
is incorrect:

        # Delete all CVSBranches rooted at this revision.  If there is
        # a CVSRevision on the branch, it should already be an add so
        # it doesn't have to be changed.

It would be easier to be certain what is happening if you would create a
test case out of your repo (it probably only requires the single RCS
file).  In fact, it would be great if you would do this anyway for our
test suite :-)

Is this holding up cvs2hg or resulting in incorrect output, or is it
just a quality-of-conversion issue?  Either way we should fix it, but
the priorities would be set differently :-)

Michael

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2390587

To unsubscribe from this discussion, e-mail: [[email protected]].