Mapping SVN usernames to git

[Dirk Stöcker]

Hello Taylor Smock,

> With that said, moving our development repositories to `git` would be a 
> required step for moving to any of the "popular" things like GitHub, 
> GitLab, or Gitea. I /would/ like to have CI configuration in the repo 
> (like GitHub/GitLab CI) since it would make it easier to figure out 
> what failed and why -- I don't have to do as much guessing at what the 
> server was doing when debugging, especially if the CI is run in an 
> ephemeral container. Jenkins does echo out commands, but there have 
> been some CI failures that were dependent upon the software installed. 
> Which were a PITA to debug.

I'm open to any improvements in the way configuration of Jenkins it's 
done. For me as server admin Jenkins is a directory where all the 
configs are stored and the working directories and the results. I hate 
that. Typical non-Unix software with no proper separation. Getting the 
configuration from of the version control system would be a major step 
forward!

> know what (exactly) about the gitlab migration was a nightmare, but I 
> /think/ it was partly due to not having a good way to transfer from 
> Trac to GitLab. I /assume/ he was just going to use the `git-svn` 
> bridge to convert from `svn` to `git` (which I'm not doing -- I'm 
> deliberately rewriting "history" so that the patch author shows up as 
> the patch author for tools parsing git commits, and committed by 
> whoever did the commit).

I'm not sure he even came to that point. It seems this software is only 
made for their servers and not really to be installed somewhere else.

> For anyone that /really/ wants to move to GitHub, I think it is 
> possible. You (the person who wants to move to GitHub/something like 
> GitHub) will need to set up some kind of mirroring system for the 
> various endpoints /keeping attribution/ and possibly supply patches to 
> make sites configurable for testing purposes. I /think/ everything but 
> `MOTD` and `Help pages` are configurable. Some of those implementations 
> may need/want a webhook call, which would require action on the JOSM 
> maintainer side in GitHub (I think stoecker would have to do this, 
> unless there is someone else with admin privileges on GitHub).

Oh sure. I don't say it's impossible. But I'm 100% sure that the people 
who request it don't want to do the necessary work. And presenting the 
API isn't the main part BTW. That's pretty straightforward. The main 
work would be to make the user interfaces, i.e. that what ATM the JOSM 
wiki is doing. There is a reason why I did choose JOSM wiki as the user 
interface. Easy access for anybody. GitHub has only easy access for 
GitHub fans.

> I don't think this is as much of an issue as I think you think it is. 
> There exists at least one Trac -> GitHub migration tool, and I believe 
> it keeps ticket history. The big thing would be deleting/renaming the 
> current repo so that the ticket numbers match up.

How often I search for some Java specifics and as a result come to a 
JOSM page where that issue was first described (in detail). That would 
be lost also with the most fancy transition tool.

> I'd test it out, but I don't want to overload the server (I don't know 
> if it tries to be fast or if it waits some period of time between API 
> calls). Even if that migration tool doesn't work, it shouldn't be /too/ 
> difficult to write a script that copies the development history; I 
> wrote a script that went through tickets looking for patches with 
> attribution information.

If you're reasonable overloading the server isn't an issue. There are 
hundreds of robots and spammers permanently accessing the server. 
Majority of traffic isn't helpful.

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