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

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

[Eric S. Raymond]

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)

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

[Junio C Hamano]

esr@thyrsus.com (Eric S. Raymond) writes:

> 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(-)
> ...
> -- 
> 		<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)

It is funny that you keep forgetting to sign-off your patches and
even send a message with no subject, but still manage to add a
pointer to your homepage and stuff at the end.

Perhaps you would need to form a habit to do "commit -s"?

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

[Heiko Voigt]

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

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

[Eric S. Raymond]

Heiko Voigt <hvoigt@hvoigt.net>:
> 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>

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

[Heiko Voigt]

Hi,

On Fri, Dec 28, 2012 at 11:42:00PM -0500, Eric S. Raymond wrote:
> Heiko Voigt <hvoigt@hvoigt.net>:
> > 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

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

[Eric S. Raymond]

Heiko Voigt <hvoigt@hvoigt.net>:
> > 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>

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

[Junio C Hamano]

Heiko Voigt <hvoigt@hvoigt.net> writes:

> Hi,
>
> On Fri, Dec 28, 2012 at 11:42:00PM -0500, Eric S. Raymond wrote:
>> Heiko Voigt <hvoigt@hvoigt.net>:
>> > 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.

I do not mind changing the documentation, but now I re-read the
change, I tend to agree that dropping the last (un)maintained
version of parsecvs may be detrimental.  Most people will not
download parsecvs from keith's page, but first will try the one
shipped with their distros, and the recent maintainer change for
that tool would not have any impact to these users.

But at the same time, by the time this change reaches these users
who may benefit by the mention of parsecvs via the distro route, the
situation may be different, so I do not think it is such a big deal.
In the longer term, if parsecvs is revived either by Eric or
somebody else, we will add the mention back to the documentation,
probably with an updated URL.

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

[Eric S. Raymond]

Junio C Hamano <gitster@pobox.com>:
> In the longer term, if parsecvs is revived either by Eric or
> somebody else, we will add the mention back to the documentation,
> probably with an updated URL.

I'm working on the revival right now. Repository generation is still
broken, and likely to remain so until I can make the export-stream stage
work, but just a few minutes ago I coaxed it into generating what looks 
like graphviz markup describing a commit graph on standard output.

Even though dot(1) barfs on the markup, this is encouraging. It almost
certainly means that the analysis and parsing stages aren't broken, and
by stubbing out enough functions I can figure out what is being passed
to the broken repository-maker well enough for my purposes.

Actually, I've already figured out how to generate blob and commit-header
markup.  The hard part is generating fileops; I don't quite understand
the generated data structures well enough to do that yet.  But I'm
making progress, and feeling more optimistic than I was yesterday.

In related news, I've sent Michael Haggerty patches that fix the visible
problems with cvs2git that I enumerated in previous mail.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Chris Packham]

Minor typo

On 12/29/2012 05:20 AM, 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.
> 
> 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:

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
>  ---
>