Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)
Hi Stuart! On Saturday, 28 January 2023 05:18:34 CET Stuart Prescott wrote: > On 27/01/2023 21:23, Diederik de Haas wrote: > Your suggestion is entirely sensible and it does no harm to start with > the updated version as you say. I'm not sure there's any functionality > in recent commits to help with the mass conversion you describe, but it > does no harm. I saw you already uploaded the new version, thanks! > > 7) Actually do the conversion > > my experience was that this was not easy in itself with quite a few > repos that were broken in some way, such as tags not being on branches, > main not being continuous in strange ways. Yeah, it'll probably be a headache. But better a big headache one time then giving each person who'd try such a thing a headache. > create a fresh git repo with all the historical uploads using > gbp import-dscs --debsnap. I'd have to import changes since the svn repos were archived, but still had to learn/figure out how to do that. You just made that easy, thanks! > There are some people who did some mass conversions of repos (python > team, qt team for instance) - perhaps it is worth reaching out to them Great tip :-) > > So I've now concluded that it's probably best to propose a mass-migration > > of the Alioth repos which haven't been converted yet (and uploaded to > > salsa). And that the Debian QA group is likely the best place to propose > > that. Hopefully there are also ppl there with more current Subversion > > knowledge and maybe even with converting SVN to Git. > > That's a huge task! That's definitely something to discuss on the > mailing list before you get too far into it. It would be worth > considering what to do with packages that are no longer in Debian at > all, for instance. It was already a huge task for 1 repo and it's actually motivating it won't be for just 1, but 'all' of them. And that then no one has to care anymore. https://lists.debian.org/debian-qa/2023/01/msg00031.html Already got a positive reaction from a person (I met at a BSP and) who is knowledgeable with programmatically querying/modifying Debian infra \o/ Cheers! Diederik signature.asc Description: This is a digitally signed message part.
Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)
Hi Diederik! On 27/01/2023 21:23, Diederik de Haas wrote: I did deliberately use 'version', while I'd normally use 'release' for these type of bugs ;-) :) Your suggestion is entirely sensible and it does no harm to start with the updated version as you say. I'm not sure there's any functionality in recent commits to help with the mass conversion you describe, but it does no harm. In order to adopt 'id3lib' (src:id3lib3.8.3): 1) I need to learn about Subversion, which hopefully is a bit easier *for me* as I had used and set up a Subversion server myself ... but that was certainly >10 YEARS ago, possibly close to 20. 2) I had rightly *guessed* there was an archive and 'muon' kindly pointed me to it ... the 'collab-maint' archive was (ofc) ~880 MB in size. ick. I pulled some things out of largeish svn repos for other teams and that was an unpleasant experience. 7) Actually do the conversion my experience was that this was not easy in itself with quite a few repos that were broken in some way, such as tags not being on branches, main not being continuous in strange ways. Almost every time I've tried it out, I've ended up running the process several times to improve the config or the options used, or the git post-processing. For a couple of packages, I decided to just ditch the svn repo and instead create a fresh git repo with all the historical uploads using gbp import-dscs --debsnap. There are some people who did some mass conversions of repos (python team, qt team for instance) - perhaps it is worth reaching out to them to find out how they did it and if their scripts are available. That might give you a head start. I don't recall who did these conversions but mailing list discussions from around the time of the move to salsa might help there, or just asking around on IRC. So I've now concluded that it's probably best to propose a mass-migration of the Alioth repos which haven't been converted yet (and uploaded to salsa). And that the Debian QA group is likely the best place to propose that. Hopefully there are also ppl there with more current Subversion knowledge and maybe even with converting SVN to Git. That's a huge task! That's definitely something to discuss on the mailing list before you get too far into it. It would be worth considering what to do with packages that are no longer in Debian at all, for instance. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)
Hi Stuart! On Friday, 27 January 2023 04:40:47 CET Stuart Prescott wrote: > On 27/01/2023 09:17, Diederik de Haas wrote: > > Package: svn-all-fast-export > > Version: 1.0.18+git20200501-1 > > Severity: wishlist > > > > It would be great if the latest version could be packaged for Debian. > > I recently had the need to retrieve a repo from the alioth archive and > > convert it to git. And this sounds like a great tool for that where > > upstream has even worked on the code in the last couple of years ;-) > > > > Anything that could make that task easier would be appreciated and a > > newer version of svn-all-fast-export may just help. > > Upstream doesn't often make releases and so the "new upstream" > notification from the watch file is only about new commits being made to > the upstream repo, not a new version being available. I did deliberately use 'version', while I'd normally use 'release' for these type of bugs ;-) > Most of the recent upstream activity has been about CI on GitHub and not > actual changes to the package. Yep, I did see that. But I did see there were also non-GH-CI related commits. I filed the bug for 2 reasons: - I think it's generally good to have the latest release/version in for the next Stable release (and I assumed it wouldn't be too difficult in this case). - What I described in the initial report and will expand on below ... > Is there anything in the recent commits that would help you? I hadn't > seen anything to justify updating the package but if there's something > specific, please say and we can do it. TL;DR: I lack the knowledge to determine that, so I don't *know*. If you determine there isn't anything useful, feel free to close this bug. I'll (very) likely try to make the issue(s) I ran into wider and send a mail about it to the debian-qa ML, but (the long version is) ... In order to adopt 'id3lib' (src:id3lib3.8.3): 1) I need to learn about Subversion, which hopefully is a bit easier *for me* as I had used and set up a Subversion server myself ... but that was certainly >10 YEARS ago, possibly close to 20. 2) I had rightly *guessed* there was an archive and 'muon' kindly pointed me to it ... the 'collab-maint' archive was (ofc) ~880 MB in size. 3) I did know about (TurtoiseSVN and) kdesvn and I found out (yesterday) that I could indeed see the repo, which hopefully will help a bit 4) Then the big thing: I want/need to convert it to git and I (highly) prefer if I can restore as much of its history as possible. But I don't know which tools are available and which are in a decent enough shape, hence why I used 'recent commits' as a criteria. I generally think using CI is a good thing, but also concluded that the recent GH CI commits were irrelevant for my purpose. But I completely lack the knowledge to evaluate the commits that were done before those. They may be irrelevant, but the issue is: I don't *know*. 5) I already learned I should (try to) create some mapping file to translate svn committers into git committers. And that I need to learn about the configuration file I should give to svn-all-fast-export as it (apparently) needs more info to make the conversion to git. 6) I should probably do the same for other svn-to-git-conversion-tools precisely as I don't know how good one tools is, which IIUC also depends on how SVN was used ... 7) Actually do the conversion 8) Upload it to salsa, which should be easy. 9) Oh wait, yeah, I almost forgot: the goal was to potentially adopt a package, so actually do something with the package ;-P And all that to potentially adopt 1 package! And everyone who thinks about adopting a package which was previously stored on Alioth, will have to go through that too. And I have previous knowledge about SVN, a reasonably fast internet connection which is (AFAIK) also unmetered/unlimited, which not everyone has. Any sane person would've long bailed out, likely already at step 1;-) So I've now concluded that it's probably best to propose a mass-migration of the Alioth repos which haven't been converted yet (and uploaded to salsa). And that the Debian QA group is likely the best place to propose that. Hopefully there are also ppl there with more current Subversion knowledge and maybe even with converting SVN to Git. But it would still be useful if the potential tools for that are in the best shape possible, so having the latest commit(s) of svn-all-fast-export packaged *may* be useful. But as said before: I lack the knowledge to determine that. Regards, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)
Hi Diederik! On 27/01/2023 09:17, Diederik de Haas wrote: Package: svn-all-fast-export Version: 1.0.18+git20200501-1 Severity: wishlist It would be great if the latest version could be packaged for Debian. I recently had the need to retrieve a repo from the alioth archive and convert it to git. And this sounds like a great tool for that where upstream has even worked on the code in the last couple of years ;-) Anything that could make that task easier would be appreciated and a newer version of svn-all-fast-export may just help. Upstream doesn't often make releases and so the "new upstream" notification from the watch file is only about new commits being made to the upstream repo, not a new version being available. Most of the recent upstream activity has been about CI on GitHub and not actual changes to the package. Is there anything in the recent commits that would help you? I hadn't seen anything to justify updating the package but if there's something specific, please say and we can do it. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)
Package: svn-all-fast-export Version: 1.0.18+git20200501-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It would be great if the latest version could be packaged for Debian. I recently had the need to retrieve a repo from the alioth archive and convert it to git. And this sounds like a great tool for that where upstream has even worked on the code in the last couple of years ;-) Anything that could make that task easier would be appreciated and a newer version of svn-all-fast-export may just help. Cheers, Diederik - -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages svn-all-fast-export depends on: ii git 1:2.39.0-1 ii libapr1 1.7.0-8 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libqt5core5a 5.15.8+dfsg-2 ii libstdc++612.2.0-14 ii libsvn1 1.14.2-4+b1 svn-all-fast-export recommends no packages. svn-all-fast-export suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY9L73QAKCRDXblvOeH7b btM6AQC8bi1gBYJt05Yr2ktw2pBmv7H2ppBPFcfR9VsFSmzKRAEAp+BgjVQLPkMq yY5WjM1b0inaVc2s1SeKHWZVPp1hsQk= =GJht -END PGP SIGNATURE-
