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 |