Mapping SVN usernames to git

Dirk Stöcker openstreetmap at dstoecker.de
Sun Nov 26 20:55:40 UTC 2023


Hello Marcello Perathoner:

>> And to be blunt → the chances to implement major rework concepts of 
>> people, who vanish when the task of setting up demonstration of the 
>> concepts come, are pretty much zero.
> 
> Also to be blunt: did it ever occur to you that the reason people are 
> vanishing might be your own attitude?

Oh yes. I'm more or less active in dozens of projects and have been 
active in probably hundred or more. I'm in close contact with many 
hundreds of projects due to my work for openSUSE. And I check all the 
time if my approach is still right or if the situation changed and my 
approach needs to be modified. I started development when OpenSource was 
developed at home by single persons and contact was made by normal 
letters (yes, these things delivered by the postman). I adapted to the 
upcoming Internet, to E-Mail to SCCS, RCS, CVS, SVN and Git. I saw the 
first Wikis and used them. I appreciated many changes and I rejected a 
lot. Many of these I rejected (and some I appreciated) you probably 
never heard of. I learned a lot over the time and I have an opinion 
based on experience and not because the typical "Git is good because I 
don't know anything else".

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.

> 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.

> 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.

> Like I said ...

Now I'm the maintainer of JOSM, a software which is mature (OpenHUB 
estimates it with over 200 years of developers effort), works well, has 
only a few bugs which are usually very obscure and hard to track down 
and happen in very rare situations. The software was a very simply 
editor for OpenStreetMap data when I took over from Frederik and today 
is more like a full featured GIS application which can be used for many 
application outside of the OpenStreetMap world. I even actually disliked 
Java and thus JOSM in the beginning and contributed to Merkaartor 
editor, a software nobody uses anymore. Now JOSM is still permanently 
improved even nowadays, where it's really hard to find any bigger 
missing features. JOSM survived the permanent fluctuation of people 
which I observe in any OpenSource project I've ever seen. JOSM was able 
to cope with the increasing requirements over the years (try any early 
JOSM version with today's data to know what I mean). JOSM survived the 
decline of Java as language from "that's the best on the market" to 
"only legacy industry application use Java".

And now let me ask you your question: Did you ever consider that your 
opinion may be wrong and that success over such a long time may not only 
be luck?

For Freedom In Peace
-- 
http://www.dstoecker.eu/ (PGP key available)



More information about the josm-dev mailing list