Source location

[xerxes]

Has there been any discussion about moving ShowEQ to GitHub.com and archiving the old SourceForge stuff? SF is full of ads, and while one never really needs to go there, I find myself missing modern abilities, such as being able to search for text in files, etc., without pulling it local.

This is one of the only projects that I use that I still visit SF to grab. It would be nice to bring it to a modern platform :)

[BlueAdept]

cn187 was talking about it. I dont know how to use Github. There is a something to move from SF to Github. I guess I need to create an account and start brushing up.

https://gist.github.com/rubo77/8f22193cf940837d000a996c7132dae0 moving with full history.

Still havent found a way to sync them though for future releases.

[cn187]

Has there been any discussion about moving ShowEQ to GitHub.com and archiving the old SourceForge stuff? SF is full of ads, and while one never really needs to go there, I find myself missing modern abilities, such as being able to search for text in files, etc., without pulling it local.

This is one of the only projects that I use that I still visit SF to grab. It would be nice to bring it to a modern platform :)


I would have been OK moving things to GitHub until Microsoft bought them. Now I'm pretty against it. They want everyone to believe that they've changed but I don't believe it for a second - I think they're playing the long con.

I'd be a little more agreeable to moving to GitLab. In fact, I'm already pushing svn commits/tags for trunk and cn187_devel (via git-svn and some scripts I cobbled together) to GitLab for CI/CD purposes. So while it's not GitHub, the GitLab interface may be a little closer to what you're after for searching, etc. See https://gitlab.com/showeq/showeq

And I for sure would like us to move to git at some point (I'd love to be able to stop using svn), but I'd even be OK with us moving to sourceforge-hosted git. Though that obviously wouldn't address your concerns.

[cn187]

Still havent found a way to sync them though for future releases.

There's not a straight forward way to sync from svn to git automatically - I had to do a bit of work to make the sync to gitlab work. If we moved to git at sourceforge, then a git-to-git sync would be easier. I know gitlab supports mirroring external git repositories, and I assume (but don't know for sure) that github does as well. I did see that sourceforge is also advertising the ability to sync from github back to sourceforge (presumably git-to-git, no svn). But I don't know if those syncs are one-way or two-way.

[BlueAdept]

I am pretty positive it is one way and is not automatic.

What ever you decide, I am ok with. Maybe use the SF git for a while and then you can move it off at a later time. Have to take into consideration for the users who are not familiar with Git like me.

[xerxes]

I would have been OK moving things to GitHub until Microsoft bought them. Now I'm pretty against it. They want everyone to believe that they've changed but I don't believe it for a second - I think they're playing the long con.
I am not a fan of Microsoft. Suffering through AzDO at work is unbearable and all of the engineers and developers I work with despise it. However, word is that they will be deprecating AzDO in the future and pushing GitHub.com on folks, which seems like a much better approach. It would take Microsoft doing a really big blunder to mess up that platform. It's going to be around for awhile, and anyone and everyone knows how to use GitHub.com these days, unlike legacy tools like svn and AzDO git :D

I'd also add that the amount of politics at GitLab are greater than Microsoft. In trying to get an issue fixed with our install of GitLab at work, those folks were very unresponsive and completely opposed to making common sense changes that the community has asked for, for years. Namely, the conflict resolution tool in the web tool works the OPPOSITE of the human brain works. Caused so much strife at work and broken deployments because new folks and folks unfamiliar with how backwards it is were innocently trying to fix their merge requests and broke everything. GitLab absolutely refused to add a toggle to address that or disable the built-in conflict resolution, and insisted that we were doing things wrong. Ever since then, we stopped using GitLab and moved to GitHub Enterprise.

[Newby]

Consider the policies of any hosted solution as well... if a given source repo has policies against reverse engineering, for example, DB could shut the project down. Or, if the repo has policies that require publishing the identities (even just email addresses), DB could use that to work out who uses the project and shut down those EQ accounts. This applies to both people who publish changes and people who just pull down code. Even if it's just the activity log that's made available to them, DB could pull ip addresses out and associate those with EQ accounts.

[BlueAdept]

SF has git, doesn't it. Cant you just use that? We know that SF has been reliable for 18 years or so.

[cn187]

SF has git, doesn't it. Cant you just use that? We know that SF has been reliable for 18 years or so.

I expect moving to SF-hosted git is what will eventually happen. Though I'm not really in a hurry - I've finally got my git-svn setup tweaked pretty well, so I can use git to interface with the svn repo. That said, I'll probably continue to use GitLab's CI/CD just out of convenience, unless SF starts offering something similar.