[PATCH] Remove the suggestion to use parsecvs, which is currently broken.

The parsecvs code has been neglected for a long time, and the only
public version does not even build correctly.  I have been handed
control of the project and intend to fix this, but until I do it
cannot be recommended.

Also, the project URL given for Subversion needed to be updated
to follow their site move.
---
 Documentation/git-cvsimport.txt | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 98d9881..9d5353e 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt

@@ -213,11 +213,9 @@ Problems related to tags:
 * Multiple tags on the same revision are not imported.
 
 If you suspect that any of these issues may apply to the repository you
-want to import consider using these alternative tools which proved to be
-more stable in practice:
+want to imort, consider using cvs2git:
 
-* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org`
-* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs`
+* cvs2git (part of cvs2svn), `http://subversion.apache.org/`
 
 GIT
 ---

-- 
1.8.1.rc2



-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

A ``decay in the social contract'' is detectable; there is a growing
feeling, particularly among middle-income taxpayers, that they are not
getting back, from society and government, their money's worth for
taxes paid. The tendency is for taxpayers to try to take more control
of their finances...	-- IRS Strategic Plan, (May 1984)

Hi,

On Fri, Dec 28, 2012 at 11:20:25AM -0500, Eric S. Raymond wrote:

The parsecvs code has been neglected for a long time, and the only
public version does not even build correctly.  I have been handed
control of the project and intend to fix this, but until I do it
cannot be recommended.

You mean: It does not build correctly with a current version of git?
Since it links with the git source code it probably needs a version of
gits source code around the time of the last commits.

Maybe you could add that information to the parsecvs compile
instructions? I think just because it takes some effort to compile does
not justify to remove this useful pointer here. When I was converting a
legacy cvs repository this pointer would have helped me a lot.

It is the tool we were/are actively using to convert old repositories at
$dayjob.

Cheers Heiko

Heiko Voigt [off-list ref]:

Maybe you could add that information to the parsecvs compile
instructions? I think just because it takes some effort to compile does
not justify to remove this useful pointer here. When I was converting a
legacy cvs repository this pointer would have helped me a lot.

I'm parsecvs's maintainer now.  It's not in good shape; there is at
least one other known showstopper besides the build issue.  I would
strongly prefer to direct peoples' attention away from it until I
have time to fix it and cut a release.  This is not a distant 
prospect - two or three weeks out, maybe.

The priority that is between me and fixing parsecvs is getting (a)
cvsps and git-cvsimport to a non-broken state, and (b) having a sound
test suite in place so I *know* it's in a non-broken state. As previously
discussed, I will then apply that test suite to parsecvs.

Heiko, you can speed up the process by (a) adapting your tests for
the new cvsps test code, and (b) merging the fix you wrote so cvsps
would pass the t9603 test.  

The sooner I can get that out of the way, the sooner I will be avble
to pay serious attention to parsecvs.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Minor typo

On 12/29/2012 05:20 AM, Eric S. Raymond wrote:

s/imort/import/

 
-* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org`
-* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs`
+* cvs2git (part of cvs2svn), `http://subversion.apache.org/`
 
 GIT
 ---

Hi,

On Fri, Dec 28, 2012 at 11:42:00PM -0500, Eric S. Raymond wrote:

Heiko Voigt [off-list ref]:

quoted

Maybe you could add that information to the parsecvs compile
instructions? I think just because it takes some effort to compile does
not justify to remove this useful pointer here. When I was converting a
legacy cvs repository this pointer would have helped me a lot.

I'm parsecvs's maintainer now.  It's not in good shape; there is at
least one other known showstopper besides the build issue.  I would
strongly prefer to direct peoples' attention away from it until I
have time to fix it and cut a release.  This is not a distant 
prospect - two or three weeks out, maybe.

So for this short amount of time you want to change gits documentation?
Is this hint causing you trouble? Are there many people asking for
support because of that?

Even if it takes some effort to get parsecvs running I would like to
keep the hint to a good and proven cvs importer.

The priority that is between me and fixing parsecvs is getting (a)
cvsps and git-cvsimport to a non-broken state, and (b) having a sound
test suite in place so I *know* it's in a non-broken state. As previously
discussed, I will then apply that test suite to parsecvs.

Heiko, you can speed up the process by (a) adapting your tests for
the new cvsps test code,

I had a quick glance at your testsuite. After building cvsps with
	make
and cd'ing into test I got a lot of error messages some saying that
cvsps was not found when issuing
	make
there. It would be great if do not need to install cvsps into my path
just for running the testsuite. 

There is no README so I am not sure how the tests are supposed to be
build in general. Due to the lack of documentation its probably easier
for you Eric to port my tests.

The structure of my tests is quite simple:

	t/  - All the tests
	t/cvsroot - A cvs module per test
	t/t[0-9]{4}*/expect - The expected cvsps output

You can copy the cvs repository modules and convert the expected cvsps
output to whatever output you want to test against. It the found
changeset ordering that is interesting.

and (b) merging the fix you wrote so cvsps
would pass the t9603 test.  

The fix was never clean and AFAIR the reason behind that was that the
breakage in commit ordering is not easy to fix in cvsps. That and
because there are other working tools out there was the reason why I
stopped working on fixing cvsps.

Cheers Heiko

Heiko Voigt [off-list ref]:

quoted

I'm parsecvs's maintainer now.  It's not in good shape; there is at
least one other known showstopper besides the build issue.  I would
strongly prefer to direct peoples' attention away from it until I
have time to fix it and cut a release.  This is not a distant 
prospect - two or three weeks out, maybe.

So for this short amount of time you want to change gits documentation?

Yes.  We should not direct people to a tool that plain doesn't work.  

I'll fix parsecvs as soon as I can.  Once I do, I will add support to the
new git-cvsimport to use parsecvs as a conversion engine, alongside
cvsps and cvs2git.

You may not have seen the first version of that patch, so I'll 
explain. The new git-cvsimport can use multiple conversion engines;
each one is expressed as a Python class that knows how to convert
git-cvsimport options to engine options, and how to generate a
command that ships an import stream to standard output.  There's
an -e option that selects an engine.

Currently there are two such classes, one for cvsps and one for cvs2git.
cvsps is the default.  When parsecvs is working, it will be the work of
a few minutes to add a parsecvs class.

The architectural goal here is to make it easy for users of
git-cvsimport to be able to experiment with different engines to
get the best possible conversion, without having to fuss with 
details of the engine invocation.

Is this hint causing you trouble? Are there many people asking for
support because of that?

No.  But as a matter of principle I am against having documentation
tell pretty lies, even temporarily. It's bad craftsmanship and bad
faith to do that.
 

There is no README so I am not sure how the tests are supposed to be
build in general. Due to the lack of documentation its probably easier
for you Eric to port my tests.

At the present state of things, I agree.  I have been so busy fighting other
aspects of this problem that I have not yet had time to separate the
test suite from the cvsps code and document it properly.

The structure of my tests is quite simple:

	t/  - All the tests
	t/cvsroot - A cvs module per test
	t/t[0-9]{4}*/expect - The expected cvsps output

You can copy the cvs repository modules and convert the expected cvsps
output to whatever output you want to test against. It the found
changeset ordering that is interesting.

Noted.  I have a copy and will port them.

The fix was never clean and AFAIR the reason behind that was that the
breakage in commit ordering is not easy to fix in cvsps.

Understood. But it's better than no fix at all.

                                                          That and
because there are other working tools out there was the reason why I
stopped working on fixing cvsps.

Once I have all three tools working and can run them against a common
test suite, several interesting possibilities will open up.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>