Re: cvs import
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Sep 14, 2006, 17:01 UTC
- Message-ID
- <45098AE0.6030409@alum.mit.edu>
- In-Reply-To
- <9e4733910609140927y30ecaa42wae0ff0597b8c3842@mail.gmail.com>
Jon Smirl wrote:
Show 16 quoted lines
> On 9/14/06, Jakub Narebski <jnareb@gmail.com> wrote: >> Shawn Pearce wrote: >> >> > Originally I wanted Jon Smirl to modify the cvs2svn (...) >> >> By the way, will cvs2git (modified cvs2svn) and git-fast-import publicly >> available? > > It has some unresolved problems so I wasn't spreading it around everywhere. > > It is based on cvs2svn from August. There has been too much change to > the current cvs2svn to merge it anymore. [...] > > If the repo is missing branch tags cvs2svn may turn a single missing > branch into hundreds of branches. The Mozilla repo has about 1000 > extra branches because of this.
[To explain to our studio audience:] Currently, if there is an actual branch in CVS but no symbol associated with it, cvs2svn generates branch labels like "unlabeled-1.2.3", where "1.2.3" is the branch revision number in CVS for the particular file. The problem is that the branch revision numbers for files in the same logical branch are usually different. That is why many extra branches are generated.
Such unnamed branches cannot reasonably be accessed via CVS anyway, and somebody probably made the conscious decision to delete the branch from CVS (though without doing it correctly). Therefore such revisions are probably garbage. It would be easy to add an option to discard such revisions, and we should probably do so. (In fact, they can already be excluded with "--exclude=unlabeled-.*".) The only caveat is that it is possible for other, named branches to sprout from an unnamed branch. In this case either the second branch would have to be excluded too, or the unlabeled branch would have to be included.
Alternatively, there was a suggestion to add heuristics to guess which files' "unlabeled" branches actually belong in the same original branch. This would be a lot of work, and the result would never be very accurate (for one thing, there is no evidence of the branch whatsoever in files that had no commits on the branch).
Other ideas are welcome.
Michael