01412: SVN still comfortable? How about migrating to git? (Open)

Summary: SVN still comfortable? How about migrating to git?
Created: 2017-06-18 12:00
Status: Open
Category: Other
From: Sven
Assigned:
Priority: 1
Version: next
OS: all

Description: Looks like PmWiki is still maintained in SVN. Is this still comfortable? I ask this of infrequent developers as well. I haven't worked with the source much in the last years but I'd imagine that if I were to start again, setting up SVN compatibility for my git would be my first hurdle and an annoying one. I found a total of two mentions of git in the devel mailing list archives, one of them relevant, but maybe the time wasn't right yet, three years ago.
For a moment I considered whether I should join the devel ML and ask there, but that's too tedious for my spoiled modern-day tastes, being used to near-daily Github/ Bitbucket/ GitLab use with code, discussion and issue tracker all on the same platform, with an option for easy WWW browser access. Looking at the devel ML's activity makes me feel exculpated for being too lazy to configure a new mailbox for the ML and joining it, so how about switching to a more integrated platform as well?
Sven June 18, 2017, at 12:07 PM

Update: Added "Browse the source online". I think this should also be on the Download page but I can't edit that one. Also the PITS needs Summary in its page titles, then my Firefox could have offered this ticket when I typed "SVN comfor" in its location bar. Sven June 18, 2017, at 12:50 PM

The link you added appears to have been last synced 2+ years ago. If you cannot update that repository ASAP, I wouldn't recommend people using that code, there have been critical vulnerabilities fixed in the mean time. --Petko June 18, 2017, at 03:17 PM

Using PmWiki for coordination/issue tracking is "The Wiki Way" (we eat our own dogfood). It *is* an integrated platform, you can have watch lists, you can be notified by e-mail or RSS or in the wiki itself for the changes, there are Talk pages for questions and for improving the documentation, you can vote in the PITS and on the Cookbook, the documentation is right here easy to fix/update, and PITS and Test groups are here so you can demonstrate any problem in the wiki itself. Github cannot compete with that kind of integration. OTOH, contributing with code is more difficult, as until now Pm preferred every commit to be done/reviewed by himself or by me. If this changes a migration to GitHub (or to a local Git repo) may be contemplated. --Petko June 18, 2017, at 03:17 PM

Well ok, considering all those features it seems the wiki way can work nice enough, it's just not yet as easy to discover all the possibilities. Maybe I'll try and help with that if I ever get really bored with too much spare time. ;-) In that spirit, I won't revert the link to where it first pointed (another copy that was just 3 days old but harder to clone), and instead try to fix the problem of browsing code via WWW right here on our integrated development platform. WebSVN looks nice in their demo, written in PHP (as far as I can tell) and is licensed as GPL v2, so how about giving that one a try? Sven June 18, 2017, at 05:47 PM

Good idea, let me think about it. --Petko June 19, 2017, at 10:03 AM

I tried to fix the UI problem of too hard to find PITS tickets via browser history, by putting a conditional title command in the PITS.GroupHeader. However, it seems to have no effect. :-( Could you have a look what I missed? Sven June 22, 2017, at 07:49 PM

Thanks for fixing it! :-) Sven June 23, 2017, at 04:09 AM

I discovered the new version input button in the PITS form. Looks like it wasn't easily feasible to automate the version comparison?

No, I just felt lazy, but your enthusiasm is contagious so I'll do it tomorrow. :-) --Petko June 23, 2017, at 05:54 PM

If we need the human reporter to compare versions visually, here's my suggestion for that part of the form: Display the correct numbers lined up perfectly below the user input. Use a text input with transparent border to achieve that with minimal browser assumptions. Make space between the numbers and the input's side borders to distract the eyes even less. (I like to center numbers in cases like this.) Include a concise version of the upgrade hint in the form area to reach those parts of audience that tend to assume that long text above the form is just usual introduction for people who've rarely used a bug tracker before.
I've made you a demo example in Test.PitsFormCheckVersionInput, even with CSS form validation for immediate feedback.
The version button in its current form wouldn't have reminded me to upgrade, but instead would have tempted me to report a wrong version, since I was convinced by a VCS misconfiguration that my checked-out (old) version was the latest release. That's why in my demo I avoid showing users the numbers at all, if their guess can be verified as just "correct" or "wrong".
Sven June 23, 2017, at 05:15 PM

Indeed, it is better to let people type their version by themselves. I added a small JS function (instead of tortured CSS) to sanitize the reported version, compare it with the latest one and display a message if they differ. See NewIssue and Cookbook:PITS. If the person has disabled JS, we can always tell her when the version is old. Thanks for the idea and for the efforts, much appreciated. --Petko June 24, 2017, at 06:32 AM