threads / patch / 32471

patchRemove the suggestion to use parsecvs, which is currently broken.

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

## tl;dr

9 messages between Dec 28, 2012 and Jan 7, 2013. Diffs are folded; open one to read it.

replies: 8people: 4as markdown or json

Eric S. Raymond· Dec 28, 2012, 16:20 UTC · lore

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(-)
Show changes to Documentation/git-cvsimport.txt +2 −4
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)
Junio C Hamano· Dec 28, 2012, 19:28 UTC · re: Eric S. Raymond · lore

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

esr@thyrsus.com (Eric S. Raymond) writes:
Show 19 quoted lines
> 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"?
Heiko Voigt· Dec 28, 2012, 23:01 UTC · re: Eric S. Raymond · lore

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

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
Eric S. Raymond· Dec 29, 2012, 04:42 UTC · re: Heiko Voigt · lore

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

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>
Heiko Voigt· Jan 6, 2013, 16:34 UTC · re: Eric S. Raymond · lore

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

Hi,
On Fri, Dec 28, 2012 at 11:42:00PM -0500, Eric S. Raymond wrote:
Show 11 quoted lines
> 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.

Show 7 quoted lines
> 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
Eric S. Raymond· Jan 6, 2013, 20:32 UTC · re: Heiko Voigt · lore

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

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

Show 9 quoted lines
> 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>
Junio C Hamano· Jan 7, 2013, 19:21 UTC · re: Heiko Voigt · lore

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

Heiko Voigt <hvoigt@hvoigt.net> writes:
Show 21 quoted lines
> 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.

Eric S. Raymond· Jan 7, 2013, 20:41 UTC · re: Junio C Hamano · lore

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

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>
Chris Packham· Jan 1, 2013, 10:05 UTC · re: Eric S. Raymond · lore

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

Minor typo
On 12/29/2012 05:20 AM, Eric S. Raymond wrote:
Show 22 quoted lines
> 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/
Show 8 quoted lines
>  
> -* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org`
> -* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs`
> +* cvs2git (part of cvs2svn), `http://subversion.apache.org/`
>  
>  GIT
>  ---
>

← back to recent threads