SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

Status
Not open for further replies.

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Could someone, without working copy changes, please update the OrbitersimBeta branch to the latest trunk? I've spent hours on this and it fails consistently and I'm now at the "throw the computer out the window" phase (something I obviously do not want to do) :compbash:
If I try to merge another branch it goes smoothly, and I can switch back and forth between the trunk and the branch without trouble.:shrug:
Anyway, I'd like somewhere to dump the half-done changes to the AerojetDAP, and as this is related to the "new" Orbiter, why not use the existing branch.

---------- Post added at 10:33 PM ---------- Previous post was at 11:59 AM ----------

Tried to update the vc branch and got the same error, so I decided to delete the whole folder and do a checkout... and I'm still having problems downloading... :facepalm:
I'm beginning to think the issue is in SF, as I'm now in a different internet connection, and a new folder doesn't fix things.

---------- Post added 04-04-18 at 03:12 AM ---------- Previous post was 04-03-18 at 10:33 PM ----------

Managed to update the vc branch without any trouble this time, but there's some witchcraft going on in the OrbitersimBeta branch as I can't do much in there. I managed once to get the merge part done, but it failed on commit. Now it's back to TITSUP in the merge. :facepalm:

---------- Post added at 07:50 PM ---------- Previous post was at 03:12 AM ----------

SF issue:
Hello,

Our DevOps team is continuing to work on the overall latency of our storage cluster.

Sincerely,

SourceForge Support
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
FYI, it looks like there has been another meltdown in the SF servers because some people are complaining that their projects lost some revisions. :uhh: :facepalm:
It looks like SSU was not affected... *crosses fingers* but to be on the safe side, lets hold on commits for now.
Anyway, this is the first "sign of life" in over a week, as SF is saying nothing except copy-pasting the same "we are looking into it" text from ticket to ticket, so I hope this TITSUP period is ending soon. :shrug:
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
FYI, it looks like there has been another meltdown in the SF servers because some people are complaining that their projects lost some revisions. :uhh: :facepalm:
It looks like SSU was not affected... *crosses fingers* but to be on the safe side, lets hold on commits for now.
Anyway, this is the first "sign of life" in over a week, as SF is saying nothing except copy-pasting the same "we are looking into it" text from ticket to ticket, so I hope this TITSUP period is ending soon. :shrug:
Maybe we could ask Xyon to set up an SVN repository for us here on O-F like he did for Doc Martin and Orbiter. This way we get rid of our dependency on S-F and their deteriorating reliability.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Maybe we could ask Xyon to set up an SVN repository for us here on O-F like he did for Doc Martin and Orbiter. This way we get rid of our dependency on S-F and their deteriorating reliability.

Why not finally switch to git?
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Switching servers: I'd say yes (especially after spending 3h last night searching for a bug in Orbiter that turned out to be caused by me being stuck in an outdated branch... thanks SF :dry:), although I really don't like making checkouts and Orbiter installations (too many this week :facepalm:). It would have to be a switch that maintains our revision history.
Anyway, I've even considered using my computer as a server for SSU :lol:, it wouldn't be online all the time, but it probably wouldn't go TITSUP for a week. :shrug:

Switching protocols: not that interested... SVN works for me. Git still needs a server, right? So tomorrow we could be +/- in the same situation... :shrug:
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
Git still needs a server, right? So tomorrow we could be +/- in the same situation... :shrug:

No. Git does not need a dedicated server. Every "client" has a copy of the full repo and could act as server if the need arises. Switching pull sources (where you get your updates from) is as easy as editing a text file then.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
No. Git does not need a dedicated server. Every "client" has a copy of the full repo and could act as server if the need arises. Switching pull sources (where you get your updates from) is as easy as editing a text file then.

Exactly. In the worst of all cases, you can even mail a USB stick to get a change to somebody else (Been there, done that.) :lol:
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Still, isn't a central server required so that everyone has a common source to pull from? Or is that something only Subversion needs?
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Still, isn't a central server required so that everyone has a common source to pull from? Or is that something only Subversion needs?

No, it is decentral, that is its big advantage. For producing releases, its better to have a build-server with its own repository to be the reference. But its not mandatory.

Instead of a central master server, its common to use a master branch as reference and branch off one or more dev branches from this reference.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
Still, isn't a central server required so that everyone has a common source to pull from? Or is that something only Subversion needs?

With SVN, the server machine has the repository with all the versions of the project. SVN clients only have checkouts of specific versions.

With DVCS systems like Git and Mercurial, every participant (in order to not use the confusing terms "server" and "client" here) is equal in the sense of having all the versions locally on the machine. If participants "pull" or "push" between each other, they exchange missing versions according to the used directional operation. Of course you can mimic the centralized SVN workflow with such a system, simply by labeling one of the participants "server" and only pulling and pushing from/to it. Most projects tend to do that, but there is no problem in simply labeling just another participant "server", if the old one is offline.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
(One of my) concerns with Git is devs "loosing" common ground, which probably doesn't happen, but I fear that as I'm used to working with the "controlled environment" of SVN. :shrug:
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
(One of my) concerns with Git is devs "loosing" common ground, which probably doesn't happen, but I fear that as I'm used to working with the "controlled environment" of SVN. :shrug:
Same here. I think the best solution is to migrate to a new server.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
(One of my) concerns with Git is devs "loosing" common ground, which probably doesn't happen, but I fear that as I'm used to working with the "controlled environment" of SVN. :shrug:

Well, SVN is also prone to losing versions. Particularly the ones during a checkin-race. Imagine you work on some feature, test it, are happy with it, and decide to "checkpoint" this version. What do you do? Well, check-in to SVN, of course! But behold, some other dev made a check-in in the mean-time, unfortunately on the same file, so your trusty SVN client tells you that it's a no-no to checkin just now, you first have to update. So you update, but unfortunately you have to merge that same file now before you can check it in.
At this point you have lost your functioning version and you have to deal with the changes the other dev has put in. So you merge, test, fix bugs due to the merge, test again, are happy, want to check-in again, and goddamit, the other dev has AGAIN checked something in before you. Your SVN client tells you to update before you can check in, and so on, and so forth, until this "race" is either won or you just throw the towel and make ZIP archives.

With DVCS, this situation is naturally solved by means of branches and merges, and the engine is so "intelligent" with merges that they are practically no-ops for the user.

But you are right: DVCS in general, and Git particularly gives so much freedom to the devs that without discipline to do early integration, you could "lose" common ground in the sense of falling too far behind of the master branch so that merging becomes a pain. Newcomers often make the mistake to forget about the pull and push part of the DVCS workflow, and only focus on the commit, which is about the same as never updating in SVN, which would put you in the same situation there.

So yeah, you should familiarize yourself with the tool. But time invested in learning Git - and the paradigm changes it brings with it - is certainly no bad idea, given that Git is the de-facto standard when it comes to modern version control. Whoever misses out on learning this will soon be losing common ground himself in the coding world :lol: .

---------- Post added at 17:24 ---------- Previous post was at 17:19 ----------

Same here. I think the best solution is to migrate to a new server.

You will just exchange one SPOF for another. But I get a deja-vu now, did we not have a similar discussion some years ago?
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Whoever misses out on learning this will soon be losing common ground himself in the coding world :lol: .

Especially the low cost of local branches is what makes git IMHO FAR superior to SVN in terms of dev ops. In SVN, people are too scared to create a branch because it will last forever.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Well, SVN is also prone to losing versions. Particularly the ones during a checkin-race. Imagine you work on some feature, test it, are happy with it, and decide to "checkpoint" this version. What do you do? Well, check-in to SVN, of course! But behold, some other dev made a check-in in the mean-time, unfortunately on the same file, so your trusty SVN client tells you that it's a no-no to checkin just now, you first have to update. So you update, but unfortunately you have to merge that same file now before you can check it in.
At this point you have lost your functioning version and you have to deal with the changes the other dev has put in. So you merge, test, fix bugs due to the merge, test again, are happy, want to check-in again, and goddamit, the other dev has AGAIN checked something in before you. Your SVN client tells you to update before you can check in, and so on, and so forth, until this "race" is either won or you just throw the towel and make ZIP archives.
Sadly, SSU doesn't have THAT much activity. :lol::(
(I'm remembering this discussion from 2 years ago (or whenever it was)) Having a policy of commit-and-push, we can keep things "aligned" as they are in SVN. It might not have to be for EVERY commit, but generally treating those 2 events as one keeps things simple.


Especially the low cost of local branches is what makes git IMHO FAR superior to SVN in terms of dev ops. In SVN, people are too scared to create a branch because it will last forever.
I'm not... I don't do it more often because it takes tons of time to download. About lasting forever, last Monday when things started to go wrong, I was actually thinking of deleting some ancient branches we have.

I still have to read a bit about branches in git.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
I don't do it more often because it takes tons of time to download.

That's the point. It takes some milliseconds with DVCS.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
That's the point. It takes some milliseconds with DVCS.

Or nothing at all. If I create a local branch on my repository, you won't see it. Maybe eventually, it might turn into a global branch which I share, because my feature is good, but not good enough and I need collaboration. But generally, I can create many local branches on my machine until finding the one that actually works. And then throw all others away.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
This might be a bad idea, but it seems TortoiseGit can give us the "distributed" part of git and allow us to keep the SVN server as is... not how much improvement it would provide when the server goes TITSUP.
I remember seeing several "large" commits from SiameseCat within seconds of each other... could (something like) TortoiseGit be the source?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
This might be a bad idea, but it seems TortoiseGit can give us the "distributed" part of git and allow us to keep the SVN server as is... not how much improvement it would provide when the server goes TITSUP.
I remember seeing several "large" commits from SiameseCat within seconds of each other... could (something like) TortoiseGit be the source?

TortoiseGit is just a front-end for Git, much in the tradition of the SVN counterpart. IMHO not a good one, though.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
And the idea of using git as a "shell" for SVN, is it any good?


BTW: page 100 :woohoo::woohoo:
 
Status
Not open for further replies.
Top