python3 version

[mirabilos]

The next Debian will release without Python, only with py3k.

Freeze should be around beginning of January 2021, so we’ll need a stable release not requiring Python any more this year.

Cc: @gcsideal

[mirabilos]

Erk… cvs2svn was just removed from Debian due to this.

[gcsideal]

Erk… cvs2svn was just removed from Debian due to this.

Yup. This request is open for over a month and no reaction at all from the developer. I think if someone still use CVS then s/he committed to do that on the long run - others could migrate to Subversion / Git long ago. Meaning I've asked for its removal from the Debian archives.

[mirabilos]

Hello László,

Yup. This request is open for over a month and no reaction at all from the developer. […] Meaning I've asked for its removal from the Debian archives.

I don’t blame you. I’m posting this here in the hopes that the developer will update the code, so it can be reintroduced. The removal caught me by surprise, but not unexpected generally. I guess I’ll have to put it into a buster chroot.

I think if someone still use CVS then s/he committed to do that on the long run - others could migrate to Subversion / Git long ago.

(I authored an svn to CVS migration tool… really hate it.) Sure, but I’m developing in CVS with interested parties who only know git so I’m using cvs2git to provide occasionally updated copies of some modules. It was of all tools I tried the most stable (despite #871734, incidentally which informed me of the removal by being closed).

[mhagger]

I wouldn't say that the project has been abandoned but rather that not many people need it anymore and basically nobody has reported any bugs lately, or needed new features. To a good approximation, it's possible for software to be "done" and just keep serving its purpose without continuing churn…

…until something like the python2 → python3 transition comes along from the outside world and makes the software unrunnable. I have no idea how much work it would be to get cvs2svn working under python3. Maybe it's trivial? Maybe it's a big pain in the neck? I do not do much Python development these days so I'm not even up to date on what has changed since Python 3.3 or so.

Off the top of my head, the main issues that would be faced by a conversion to Python 3 would be

• Unicode strings (as usual).
• cvs2svn makes very heavy use of cPickle, including some obscure features. It's quite possible that that package has changed enough to cause problems.
• cvs2svn doesn't systematically use new-style classes. On the other hand, I can't think offhand of reasons that it would care about the difference.

I don't expect to have time to work on this. If somebody wants to volunteer to do the conversion, I wouldn't object. The test suite is pretty good and covers at least some Unicode issues, so it might not be that risky.

It might be that users of the future need to run this in a python2 Docker container or something. I don't think that should be a problem from a security standpoint, given that it doesn't access the internet or anything (assuming that you're not trying to convert possibly-malicious CVS repositories).

[cacsar]

Running it in a docker container was what I was going to look at. There are old unmaintained projects floating around in things like sourceforge where someone trying to pick them up would need cvs2svn to turn them into svn or git.

[mirabilos]

cacsar dixit:

Running it in a docker container was what I was going to look at. There

Bleh, no docker, but I guess I could run it in a Debian buster chroot. I “just” need to bind-mount all my repos and repo copies into it.

are old unmaintained projects floating around in things like sourceforge where someone trying to pick them up would need cvs2svn to turn them into svn or git.

That, too (this is actually also the case at $dayjob where we have a multi-Gibibyte old CVS repository where we occasionally extract old projects from and put into git for new development), besides my use case of exporting subprojects that are actively developed in CVS into git so hipsters can access the source code. bye, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you 13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺ 16:06⎜<Draget:#cvs> Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty 17:14⎜<ldiain:#cvs> Thanks big help you are :-) <bioe007> mira|nwt: ty again 18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o 18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 23:03⎜«mithraic:#cvs» aaah. thanks 18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-) 18:10⎜«sumit:#cvs» mirabilos: oh ok.. thanks for that 21:57⎜<bhuey:#cvs> yeah, I really appreciate help 18:50⎜«grndlvl:#cvs» thankyou 18:50⎜«grndlvl:#cvs» worked perfectly 20:50⎜<paolo:#cvs> i see. mirabilos, thnks for your support 00:36⎜«halirutan:#cvs» ok, the obvious way:-) thx 18:44⎜«arcfide:#cvs» mirabilos, I am running OpenBSD. 18:59⎜«arcfide:#cvs» Hrm, yes, I see what you mean. 19:01⎜«arcfide:#cvs» Yeah, thanks for the help. 21:33⎜«CardinalFang:#cvs» Ugh. Okay. Sorry for the dumb question. Thank you 21:34⎜<centosian:#cvs> mirabilos: whoa that's sweet 21:52⎜«garrett__:#cvs» much appreciated «garrett__:#cvs» thanks for your time 23:39⎜<symons:#cvs> this worked, thank you very much 16:26⎜<schweizer:#cvs> ok thx, i'll try that 20:00⎜«stableable:#cvs» Thank you. 20:50⎜«s833:#cvs» mirabilos: thanks a lot. 19:34⎜<bobbytek:#cvs> Thanks for confirming :) 20:08⎜<tsolox:#cvs> ...works like a charm.. thanks mirabilos

[futatuki]

* Unicode strings (as usual).

Subversion Python 3 bindings maps all char * types in C API to Python bytes objects, and rcsparse in ViewVC in master also parse CVS as bytes stream[1], so it seems it is not so large problem on conversion to Subversion repo. Though I'm not sure about hg, bzr, and git.

[1] viewvc/viewvc@eef060e#diff-0c54e198c9e0d028e25782dbe40c95e8,
viewvc/viewvc@36d4ccd#diff-0c54e198c9e0d028e25782dbe40c95e8

[mirabilos]

FUTATSUKI Yasuhito dixit:

Subversion repo. Though I'm not sure about hg, bzr, and git.

The still-working version from Debian unstable before removal already failed to import into then-current git, so I switched to using it from a buster chroot ☹

[futatuki]

Subversion Python 3 bindings maps all char * types in C API to Python bytes objects, and rcsparse in ViewVC in master also parse CVS as bytes stream[1], so it seems it is not so large problem on conversion to Subversion repo.

I looked over again the code of rcsparse on ViewVC, it is incomplete how to handle non-ascii metadata, and the result of the metadata are held as str objects, decoded by 'ascii' codec with 'surrogateescape' error handler.

Anyways, I'll make a PR to update rcsparse, for those who want to work for Python 3 support of cvs2svn, although I myself don't not work for it, at least now.

[makefu]

Hi all, NixOS is also on the verge of going py3-only and cvs2svn will be most likely deleted ( NixOS/nixpkgs#148779 ).
Anyways thanks for all your efforts!

[clach04]

I briefly considered tackling Python 3 support but using crap was significantly less effort for a project conversion I did today. crap works remotely and does NOT need direct, filesystem access to a copy of the CVS repository.

Doc ref for anyone who finds this and is looking for alternatives.

cvs2svn can be used to convert to hg/mercurial (cvs2hg) and git (cvs2git), possible alternatives for those:

• https://github.com/rcls/crap - essentially cvs2git
• https://www.mercurial-scm.org/wiki/ConvertExtension - hg convert essentiall cvs2hg - with cvsps
• cvs-fast-export

py3 support may still be useful for direct access use cases if anyone has the time/energy.

[mirabilos]

clach04 dixit:

a project conversion I did today. crap works remotely and does NOT need direct, filesystem access to a copy of the CVS repository.

Hmh. Without direct repo use, the tools are usually either too slow and/or have issues with RCS IDs, in my experience… not that cvs2svn as cvs2git is fast… or has no issues with content for old revisions either… but at least it’s mostly usable for pushing to GitHub after some commits so today’s CVS-illiterate developers can read it… bye, //mirabilos -- <ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^ <mika> sorry, no idea and rebasing just fscked │<mika> Segmentation <ch> should have cloned into a clean repo │ fault (core dumped) <ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh

[clach04]

I got lucky today, the repo was tiny and only spaned a few years.