Mapping SVN usernames to git

[Taylor Smock]

On 11/26/23 3:15 PM, Michael Zangl wrote:
>>> 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")

`svn` /technically/ has bran`ches, but I haven't used them -- from what 
I understand, they are commits and are counted by the method we use to 
generate the JOSM version.

I /would/ really like to have tests run on the patch before I look at 
it, just to reduce headaches. There have been times where I've run tests 
on patches, but didn't run the /right/ test. I have made some 
improvements on the testing side (local test times are <10 minutes for 
me now, instead of 20+ minutes).

>>> 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". 
I'm OK with old stuff breaking, so long as it is fixed inside a 
reasonable time. The problem here is that very few people have access to 
that tooling (which is both a good thing (security) and a bad thing (bus 
factor)). Stoecker, understandably, doesn't want to have to fix 
something inside a reasonable time, so that is something to keep in mind.
> 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)
>
> [...]

I poked the Maven/Gradle ticket again ( 
https://josm.openstreetmap.de/ticket/8269 ) since I don't want to have 
two different locations to set a variable every time we increase the min 
Java version. Please continue this conversation there or start a new 
josm-dev thread.


Like I'm saying in my other replies, all I'm asking for right now is a 
mapping of svn user -> git attribution. I am especially interested in a 
mapping for people who might be attributed with a `patch by <foo>` line. 
The first responder also included their OSM username, which ended up 
being how they had been attributed.


Have a good day,

Taylor