Author Topic: Sourceforge died. (Read 15289 times)

Zorchenhimer · « **on:** July 22, 2015, 01:57:13 PM »

It looks like SorceForge took a dive last week and it still isn't fully recovered. This means that the CVS repository is inaccessible (link). The one project I had on SourceForge had its Git repository wiped and I'm still waiting to see if the SVN version ever comes back up.

I fear that the CVS repository for Paintball has been lost. Normally that would be horrible, but I had started to mirror the repository on my Git server (link) sometime last month. The last commit I have is from the day before everything hit the fan (2015-07-14), nothing is actually lost even if SourceForge never restores itself.

I guess the reason I'm making this post is to ask weather or not Jitspoe has considered moving the code to a Git repository. Maybe now would be a good time to consider moving away from SourceForge to something a bit better?

mRokita · « **Reply #1 on:** July 22, 2015, 04:31:08 PM »

Yes, move to GIT it's much better

jitspoe · « **Reply #2 on:** July 22, 2015, 08:14:49 PM »

Wow, that's a pretty serious blow to sourceforge, since it seems like it was already on a downhill trend.

What are the advantages to git? I've heard it's kind of awkward to use but I've never used it myself. CVS was super simple with TortoiseCVS -- I'd just right click on the files/directories in explorer and submit/sync/whatever.

Thanks for creating the mirror. We might need it. I'll see if they manage to get everything restored -- looks like they're actively working on it.

Ace · « **Reply #3 on:** July 22, 2015, 09:17:34 PM »

There is a Tortoise git if it makes you feel better (https://code.google.com/p/tortoisegit/)

I don't think there's a huge advantage to one over any other. It's preference, but I think git is significantly easier to use once you are used to the weird syntax.

Zorchenhimer · « **Reply #4 on:** July 23, 2015, 12:48:56 AM »

Quote from: jitspoe on July 22, 2015, 08:14:49 PM

Wow, that's a pretty serious blow to sourceforge, since it seems like it was already on a downhill trend.

What are the advantages to git? I've heard it's kind of awkward to use but I've never used it myself. CVS was super simple with TortoiseCVS -- I'd just right click on the files/directories in explorer and submit/sync/whatever.

I could never really figure out CVS/SVN, not that I've tried really hard. However I hear that branching/merging is a nightmare. Branching and merging in git is really smooth, and it can handle three way merges pretty well. Once I learned how to use git I started to use it for all my projects. Git has many advantages, one being that there is no need for a central dedicated server for repos. Everyone who clones/checkouts a repo has a full copy of it including the history. When I found out that my Git repo on sourceforge was wiped, I simply pushed to it from my local machine and I've got the full commit history again on sourceforge.

For some detailed stuff see here: https://gist.github.com/btilford/716213

There are a few tools for git (including first party plugins for Visual Studio 2015, if you use that), but the one I use the most on Windows is GitExtensions. The web view stuff is managed with cgit for the front-end and gitolite managing the repos and user permissions.

Quote from: jitspoe on July 22, 2015, 08:14:49 PM

Thanks for creating the mirror. We might need it. I'll see if they manage to get everything restored -- looks like they're actively working on it.

I've been meaning to ask about this for a while, and sourceforge taking a dive prompted me to stop procrastinating. I've heard some rumors about their backend, and it doesn't sound good. If you want, you can send me your public key and I can give you write access to the git repo.

jitspoe · « **Reply #5 on:** July 23, 2015, 10:37:54 PM »

Ah, I never use branching, and merging doesn't happen much with a project this small. Merging really just depends on the quality of the merge applications you're using, since it's all done client side.

"In Git your working copy is a clone of the entire repository."

Ugh... that's one of the things that turned me off from SVN. Super bloated, especially if you have a large project with a lot of history. Takes up massive amounts of disk space.

Zorchenhimer · « **Reply #6 on:** July 24, 2015, 02:14:34 AM »

Quote from: jitspoe on July 23, 2015, 10:37:54 PM

"In Git your working copy is a clone of the entire repository."

Ugh... that's one of the things that turned me off from SVN. Super bloated, especially if you have a large project with a lot of history. Takes up massive amounts of disk space.

The only repo I've seen that's borderline unmanageable due to its size is the unreal engine at ~27k commits and 13 branches.

I'm not very good at describing it's strong points against CVS though, only because I've never really used CVS. Linus Torvalds has a really good talk at Google about CVS and Git if you have about an hour to spare: https://youtu.be/4XpnKHJAok8

He goes over the whole distributed architecture of git, why it's a good thing, and why CVS is terrible.

Edit:
Btw, the repo for paintball is really small. The git stuff is only 4Mb (paintball2/.git/).

Code: [Select]

$ du -hd 1
1.3M	./tools_src
2.0M	./serverbrowser
9.7M	./paintball2
13M	.

$ du -hd 1 paintball2/
56K	paintball2/extern
256K	paintball2/linux
4.1M	paintball2/.git
128K	paintball2/game
844K	paintball2/client
24K	paintball2/a3d
208K	paintball2/server
16K	paintball2/xfire
2.2M	paintball2/ref_gl
292K	paintball2/qcommon
168K	paintball2/bots
1.4M	paintball2/win32
9.7M	paintball2/

xrichardx · « **Reply #7 on:** July 29, 2015, 12:44:57 PM »

The CVS repository is back up on sourceforge, see http://paintball2.cvs.sourceforge.net/viewvc/paintball2 , but currently I still can't do a checkout. I guess it will be completely usable again in the next 24h.

Still, I'd prefer moving to git because I like it's decentralized and fast approach. Checking out a single file for viewing differences took / takes ages with CVS..

webhead · « **Reply #8 on:** July 29, 2015, 01:24:53 PM »

I would hope it could be moved not only to Git, but to Github specifically (obviously only the open-source parts) because it could really be a boon for the game's development. Github has a great community of coders and with Pull Requests, getting help on development takes minimal effort on the part of the project manager(s) -- just look over the PRs that are submitted and if they're good enough, hit a button to merge them in.

So I would say the binaries of the closed-source parts should be distributed in the Github repo, and developed as a separate project with, say, Bitbucket (because they allow you to host private Git projects for free whereas Github would charge for that).

I feel very strongly about this so I would love to see this happen. Also, Github has the ability to host binary downloads like SourceForge, as well as static web pages and/or a Jekyll blog for the project, if that matters.

mRokita · « **Reply #9 on:** July 29, 2015, 01:30:15 PM »

Quote from: webhead on July 29, 2015, 01:24:53 PM

I would hope it could be moved not only to Git, but to Github specifically (obviously only the open-source parts) because it could really be a boon for the game's development. Github has a great community of coders and with Pull Requests, getting help on development takes minimal effort on the part of the project manager(s) -- just look over the PRs that are submitted and if they're good enough, hit a button to merge them in.

So I would say the binaries of the closed-source parts should be distributed in the Github repo, and developed as a separate project with, say, Bitbucket (because they allow you to host private Git projects for free whereas Github would charge for that).

I feel very strongly about this so I would love to see this happen. Also, Github has the ability to host binary downloads like SourceForge, as well as static web pages and/or a Jekyll blog for the project, if that matters.

+1
for a private git repository, i recommend GitLab [http://gitlab.com], you can host it on your own linux server.
I can help with it since i've been installing it from source this week.

Zorchenhimer · « **Reply #10 on:** July 29, 2015, 09:47:10 PM »

Quote from: xrichardx on July 29, 2015, 12:44:57 PM

The CVS repository is back up on sourceforge, see http://paintball2.cvs.sourceforge.net/viewvc/paintball2 , but currently I still can't do a checkout. I guess it will be completely usable again in the next 24h.

At this point I don't know if I'd trust that the CVS source tree is free of data corruption. There is no data validation in CVS whatsoever. Git on the other hand uses sha1 hashes to identify commits. If you can verify that the commit hash is correct (40 characters), you can be sure that the commit you are looking at is valid as well as the entire history connected to that commit. Relevant part of Linus' talk: https://youtu.be/4XpnKHJAok8?t=56m20s

xrichardx · « **Reply #11 on:** July 30, 2015, 09:48:37 AM »

I watched the whole video already when you posted it the first time.

I downloaded the tarball from sourceforge and compared it against your git repository. For all files, the line endings were changed (I checked some, these were identical when ignoring linechange differences), so I created a local git repository and commited all the CVS files in there. After deleting all files and reverting via git, all git-transformations were also done to these (so the line endings were also the way git wants them to be). Then, i diffed them with winmerge which gave me three files that were different:

refgl/glidesys.h
refgl/glideutl.h
refgl/sst1vid.h

In all three, just the $HEADER line was changed from /cvsroot/paintball2/paintball2/ref_gl/filename to /cvsroot-fuse/paintball2/paintball2/ref_gl/filename.
Since that is inside a comment, it should not do any harm.

All other files were identical. I guess that is enough validation.

Zorchenhimer · « **Reply #12 on:** July 30, 2015, 02:40:28 PM »

Quote from: xrichardx on July 30, 2015, 09:48:37 AM

Then, i diffed them with winmerge which gave me three files that were different:

refgl/glidesys.h
refgl/glideutl.h
refgl/sst1vid.h

In all three, just the $HEADER line was changed from /cvsroot/paintball2/paintball2/ref_gl/filename to /cvsroot-fuse/paintball2/paintball2/ref_gl/filename.
Since that is inside a comment, it should not do any harm.

And that right there makes me a suspicious. Is CVS modifying these files? None of the versions of these files in git has the "/cvsroot-fuse/" version. The last time these lines were ever touched in a commit was nine years ago (twelve for sst1vid.h). When was this change made? When the repo was restored from a backup? Source control should never be modifying the source on its own.

The fact that anything is different from what was pulled two weeks ago raises flags. In fact you've convinced me that SourceForge cannot be trusted with the source tree. Especially if it's hosted in CVS.

xrichardx · « **Reply #13 on:** July 30, 2015, 03:09:48 PM »

This is what happened there: http://www.badgertronics.com/writings/cvs/keywords.html

Still, I agree with you, this should not be default behaviour and I also think git would be better. I just wanted to point out that Sourceforge did their job in uploading recent back-ups and that nothing got corrupted. The problem of these three files getting changed is a CVS problem.

Zorchenhimer · « **Reply #14 on:** July 30, 2015, 07:45:07 PM »

Quote from: xrichardx on July 30, 2015, 03:09:48 PM

This is what happened there: http://www.badgertronics.com/writings/cvs/keywords.html

Lolwut? The fact that CVS would even need this makes me laugh a bit. Jitspoe, please abandon CVS. :x

jitspoe · « **Reply #15 on:** September 01, 2015, 08:20:44 PM »

One thing I noticed with git when I was putting my starviewer up on it is that it had to have an empty directory, then it created a subdirectory within that directory for the source, so I had x:\projects\starviewer\starviewer. Is it possible to avoid that?

It was even funnier because the game mod directory was starviewer, so I had x:\projects\starviewer\starviewer\starviewer.

Zorchenhimer · « **Reply #16 on:** September 01, 2015, 09:42:24 PM »

~~That's just a Git Extensions thing. Idk why it does that.~~ Actually, I can't get it to do that for me.

xrichardx · « **Reply #17 on:** September 02, 2015, 08:53:57 AM »

Also, creating a repository with TortoiseGit should work fine inside a non-empty folder. It did it for me (and still does), by just going to the project folder (X:\projects\starviewer) and selecting "Git Create repository here..." in the context menu. Do not check "Make it bare", just click OK.

jitspoe · « **Reply #18 on:** September 03, 2015, 12:19:19 AM »

Ah, I was just using the application that came from GitHub.

webhead · « **Reply #19 on:** September 03, 2015, 02:12:57 AM »

Quote from: jitspoe on September 03, 2015, 12:19:19 AM

Ah, I was just using the application that came from GitHub.

oh the desktop client? I haven't used it a ton, but when I did, I don't recall having trouble with the directory structure matching.
In any case, if you want real power, I like the look of Git for Windows - it has the CLI, a full-featured GUI, and shell integration like TortoiseSVN. (Haven't tried it myself.)