Mapping SVN usernames to git

[Michael Zangl]

Hi

Am 26.11.23 um 21:55 schrieb Dirk Stöcker:
> I changed the way I work many times over the years and for JOSM I even 
> allowed changes which I thought were wrong when other team members 
> requested them vehemently enough. Usually I had to care for the 
> fallout later, sometimes I was wrong.
>
> One thing was always true: I NEVER requested a project to change the 
> way it works, so that I can contribute. I adapted my style to the 
> project rules or I did not contribute.

Just to clarify, why I personally requested those changes: They were not 
for the way I add my contributions. I suggested those, because I noticed 
how hard it was to set up JOSM for GSoC students (and of all other 
people interested in development).

I can contribute to JOSM (although some of my contributions did not get 
applied, due to the complexity of patch management, which led to a lot 
of frustration and loss of enthusiasm on my side and probably has 
contributed a lot to me not contributing any more - I like contributing 
to open source for free, but when writing for the trash can, I rather 
take some money for it).

>> You claim your time is limited, yet you cling to the most 
>> time-consuming way of distributed development: to apply patches by hand.
>
> Sorry, but did you ever maintain a software? Applying a patch takes 
> about 3-10 seconds. Reviewing the same patch 5-60 minutes (sometimes 
> much more). These few seconds simply don't count at all. Asking that 
> question shows that you have no idea what you're talking about. While 
> the fine grained commits of Git allow finer review that also means 
> review times increase.

Yes, it is exactly those 60 Minutes that are the problem: Reviewing a 
text file, applying it as a test, reverting since there is an error, 
writing that error back into a discussion, then after getting a new 
patch making a diff of the patches, then applying again, then running 
the relevant tests locally to see if they work, then ...

All things that a modern CVS (git, mercurial, ...) has branches for 
(except for running the tests: For this, you include a CI configuration 
for "forks")

>> If you don't like github you can self-host an instance of gitlab or 
>> forgejo or whatever github-clone-of-the-day you like best. If you own 
>> the server the changes in tooling from SVN to git should be minimal.
>
> If you would have read the thread you would have read that Vincent 
> exactly tried this, and it ended with no result after a lot of work 
> went into it. And a sentence like "changes in tooling from SVN to git 
> should be minimal" again tells me that you have no idea what you are 
> talking about.
>
It is quite easy.

The problem is not moving JOSM to GIT itself, the problem is a lot of 
custom-build tooling around the Repository/Trac that hardcodes SVN and 
that will break. And the problem was, that "none of the old stuff may 
break". For those not participating in that long, long discussion: One 
idea was to move away from having two independend build systems (ANT + 
Eclipse) that are not really popular any more to a generic one supported 
by most modern IDEs (maven or gradle) with the idea of not having to 
maintain the two old ones. We aborted this because a requirement would 
have been, that both old build systems still work.

And my personal problem with working on the build system was, that I did 
not have any source for it. So participating in it is a pain, since I 
cannot run the builds locally (since I don't even know how the CI runs 
the different tasks)


> OpenHUB estimates it with over 200 years of developers effort

Of which is 50 Years hand-writing SVG files. And 10 years that someone 
took to type all of the webatlas response into a text editor. So I take 
it back: Applying the patches by hand is not such a big deal, there are 
other things we need to work on 😂 So if we continue comparing it to 
sending text letters around, we might stay at the current workflow for 
quite some time.


Michael