News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

SVN is down

Started by An_dz, March 06, 2014, 06:06:10 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

An_dz

The SVN looks down for at least 2 days.

prissi

I guess this is rather a dyndns Problem like the last two times. They bough homeunix org last year or so it seems. I wrote and Email to the maintainer.

Ters

If this keeps happening, we really need to consider moving the repository to a more reliable place. Or even switch to some DVCS, although I'd really miss the intuitiveness of being able to report bugs against a global increasing integer revision number.

Markohs

that server has a dynamic ip?

If it's a static address, why not just add "svn.simutrans.com"?

If anyone supplies me a "svn dump" of the repository I can serve it from my cloud computer, or we can host it in any of our servers, Isaac exposed in the past he has enough available machines.

Ters

Quote from: Markohs on March 07, 2014, 08:33:23 AM
If anyone supplies me a "svn dump" of the repository I can serve it from my cloud computer, or we can host it in any of our servers, Isaac exposed in the past he has enough available machines.

My impression from last time isn't the ability to move the repository someplace else, but the will to move it someplace else. (pak64, and I think also some other pak sets, are hosted at out sourceforge project. There is probably only one svn repo per project though, and I don't know if importing one svn repo into another will work without making a mess.)

Markohs

Using svn dunp/import works,  and keeps all the repo properties. We use it at work for moving repos across servers

Markohs

Quote from: Markohs on March 07, 2014, 06:13:52 PM
Using svn dump/import works,  and keeps all the repo properties. We use it at work for moving repos across servers

Ters

Moving repos is one thing. Merging one repo into another is something different. For one thing, at least one of them will have to give up on it's original revision numbers.

Markohs

Well, I wasn't talking about merge, as you pointed sequential revision numbers are better independent across projects. I was just pointing that uf the dns or server is not reliable any longer, we should host it somewhere else. A dedicated svn for the source code is ok imho.

Ters

Quote from: Markohs on March 07, 2014, 06:38:28 PM
Well, I wasn't talking about merge

No, but I was, since we already have an existing, stable, official svn repo.

prissi

The server changes IP daily, thanks to Deutsche Telekom. And not able to access it means also not able to dump it ...

Ters

And when we have access, there is no need to dump it...

An_dz

I've split the topic because it went off-topic and the SVN is still down. And homeunix.org all together is down.

Ters

If all else fails, there is still the github mirror, but I guess we can wait one more week.

This is kind of the opposite of another open source project I know about. There the repo is still up, because it's on sourceforge, but everything else (including forum) is now completely gone. (First the DNS stopped working, but using the IP still worked for a while.)

Isaac Eiland-Hall

I've tried to play with svn and can't get my head around it. But if someone wants root to get it working on the server, just let me know.

Ters

My own private SVN server, or rather SVN plugin in Apache, has been up so long I don't remember how I got it running. As far as I can remember, it was well documented. I have never tried a pure SVN server, which likely requires doing more in terms of start-up scripts and a different authentication scheme.

The best person to help move the SVN repo is likely the current maintainer. If that person doesn't get in touch, git is all we got anyway. One can run an SVN client agains GitHub, so most users shouldn't need to adapt. I don't know how committing works in that case, as I have never been able to try.

Markohs

If at the end you decide to set-up svn in Iaac's servers, I can do the work if you want it.

prissi

If this does not resolve soon, we may indeed need to swap to github (and I deleted my account there just two months ago do to my frustration with the github client on windows ... )

Markohs

I'd personally stick to svn.

The sequential revision numbers, patching is way easier, and the windows client is way better.

Github adds lots un unneeded complexity, imho.

But ofc, this is just my personal oppinion.

prissi

A sequential revision number could be done to git as well using hooks, i.e. submit scripts. Although those cannot run on free github, I think.

Markohs

 Why changing a system that has been working good enough for us. I'd just install the svn in Isaac's servers and forget about it. Changing to github is ofc, possible, but it's really worth it?

I tried working with it, and I find it complex, too complex, and no useful new feature in exchage.

Ters

I too prefer to stick with Subversion, but unless we can somehow convert a Git mirror back to Subversion, we need to get in touch with the maintainer. Since Git does thing very differently from Subversion, quite the opposite by design, this might be a lossy process.

isidoro

I dare suggest a backup policy too.  That would also help in cases like this one.

Markohs

Let me do some tests, maybe this works:

http://chani.wordpress.com/2012/01/25/the-easy-way-to-import-from-git-into-svn/

I'll see if I can get a svn repo from the git one

Markohs

#24
Managed to get the export to svn working, but it's missing details, like the original author, the date, and the original revision number, that's lost. I'll investigate further to check if some of those details can be preserved.


The guide I followed:

http://sandrotosi.blogspot.com.es/2010/02/migrate-git-repo-to-svn-one.html

prissi

#25
On the page you link I find:
Quote@Chris you can add the --add-author-from option to git svn dcommit to have a From: header added to the svn
revisions specifying the original author.

EDIT: Could with this technique the code go into the SF svn ... that would certainly not go down quitely. Although it had it hickups in the past too (around 2007).

Markohs

I'd personally install the svn server in one of isaac's servers, and use SF one to mirror it. I can add a web frontend to the server so you can add and remove svn users easily.

But well, I don't know how easy is to add users and permissions to the SF svn server, and how much control they give to us.

Markohs

After extra research, you can preserve the commit author property, and *maybe* the commit date, doing some script magic.

What's *almost* impossible to preserve is the commit version of each one, specially since branches/* were not mirrored in github, and that part of information is lost.

What whould really be ideal is tron generating a "svn export" of the repository.

Given that, and following isidoro's comment, we need to have a online backup of the whole repository one way or another, in the future, using svn or git or whatever, but we need it.


Ters

If the goal is the import to Sourgeforge, the revision numbers can't be preserver anyway. Another possible problem is that without a proper export and import, it is likely that one can't just switch existing working copies to the new repo.

Dwachs

I have a local git-svn clone of the complete svn repository including branch/. If that is of any help
Parsley, sage, rosemary, and maggikraut.

Markohs

Can you upload me that repo to make some tests Dwachs please?

wernieman

@dwach
You mean with "git over svn"?
I hope you understand my English

Isaac Eiland-Hall

Note: One minor temporary wrinkle: I'm about to announce in Web Admin group that I've gotten a new server to transition to. It'll be faster -- and cost the same. Switching because they've added on a small "old server" fee because we've been on this one for so long. lol.

It should be a painless transition for sites -- but does mean that :if: SVN is set up on the server, we'll of course want to do it on the new one.

I should have the server released to me tonight -- but transferring stuff means it may be 2-3 days (or maybe upwards of 5 probably at worst) before we'd want to do this (to make sure DNS propagates and such).

So just a minor heads up :)

Now, back to your regularly schedule debate by you guys :)

Ters

I'm getting a bit worried about the maintainer. Does anyone know any details about the person so as to try alternative contact methods that are more likely to give some kind of response from someone?

Markohs

Nope,  we should start thinking what to do. Prissi and dwachs might know more