| 1 |
On Thu, Oct 04, 2012 at 05:45:40PM +0200, Michael Haggerty wrote: |
| 2 |
> Another big boost for cvs2git is to use the ExternalBlobGenerator, which |
| 3 |
> extracts revision contents to a "blob" file in CollectRevsPass using an |
| 4 |
> external script, thereby making OutputPass much faster. |
| 5 |
|
| 6 |
This still sequential, or can it effectively run in parallel? I'm |
| 7 |
just wondering if the 'faster' is via parallelism, or bypassing a |
| 8 |
slower native python implementation. |
| 9 |
|
| 10 |
|
| 11 |
> By the way, the PostgreSQL project converted their repo directly to git |
| 12 |
> using cvs2git and did an extremely careful audit of the results. |
| 13 |
> cvs2git is still missing a few bells and whistles (for example, |
| 14 |
> .cvsignore files are not converted into .gitignore files, and things |
| 15 |
> like EOL conversion and keyword expansion are missing and/or awkward to |
| 16 |
> use). But other than that I think it is very much ready for production |
| 17 |
> use. Definitely use version 2.4.0, which I just released, as it |
| 18 |
> includes all the new goodness. |
| 19 |
|
| 20 |
Grok; w/in limits, going custom/tip-of-tree is an option also. |
| 21 |
|
| 22 |
If memory servers, where we hit major issues was in dealing w/ |
| 23 |
encoding- crap like names, some bad latin-1 sort of data. Will have |
| 24 |
to re-run this and check. |
| 25 |
|
| 26 |
Re: pgsql, good to here- they don't have our whacked tree structure, |
| 27 |
but I'm sue the encoding sort of issues we had, they probably had a |
| 28 |
couple of. |
| 29 |
|
| 30 |
As for .cvsignore, at least for gentoo-x86 (repo in discussion), we've |
| 31 |
got none of that in use- so non issue, but for our other repos, yeah, |
| 32 |
it'll come up. Manually translating and stacking a commit on top of |
| 33 |
the results is perfectly acceptable (your tools already cover 99% |
| 34 |
after all). |
| 35 |
|
| 36 |
|
| 37 |
> > One thing to keep in mind with our tree; it's not exactly your |
| 38 |
> > standard source tree- for ebuilds, they sohuld up, rarely get |
| 39 |
> > modified, then get rename to -r{whatever}, or slightly tweaked and as |
| 40 |
> > a new version. |
| 41 |
> > |
| 42 |
> > If memory serves- and it's 4am, so that trust is limited- the reasons |
| 43 |
> > for cvs2svn path were speed for our peculiar vcs history, and bugs in |
| 44 |
> > the cvs2git direct pathway. |
| 45 |
> |
| 46 |
> More details and/or bug reports would be much appreciated if the |
| 47 |
> problems still exist in the 2.4.0 release (which is just out, though it |
| 48 |
> is well-used code with hardly any recent changes). |
| 49 |
|
| 50 |
Honestly, I couldn't give you the details; that code I started from in |
| 51 |
'10 was inherited; it was already a year old branching/release, w/ |
| 52 |
local modifications before I got started (I do recall verifying that |
| 53 |
the modifications were necessary, else things failed miserably). |
| 54 |
|
| 55 |
I'm thinking I'll just restart the process from scratch; need to |
| 56 |
anyways, can't use u-s to shave half the time off. |
| 57 |
|
| 58 |
On that note; anyone on this list doing this sort of |
| 59 |
investigation/conversion already, or locked in, guranteed they'll do |
| 60 |
it? |
| 61 |
|
| 62 |
If not, I'll try to batch this sucker to one of my machines over the |
| 63 |
next few days, and start the process. |
| 64 |
~harring |
Archives