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

Status
Not open for further replies.

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
And the idea of using git as a "shell" for SVN, is it any good?


BTW: page 100 :woohoo::woohoo:
Isn't the problem still the same even if we switch "shell"? SVN still requires a centralized server which brings out back to square one which is S-F's notorious unreliability. Should I send a PM to Xyon requesting a Subversion set up?
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Isn't the problem still the same even if we switch "shell"? SVN still requires a centralized server which brings out back to square one which is S-F's notorious unreliability. Should I send a PM to Xyon requesting a Subversion set up?

I don't know if it still wouldn't keep all things in each computer.
It would us to keep making revisions in our computers (and all the branch stuff), even when SF is offline. Not sure if we could share the work in that situation.

A question about git: it still needs a "head", a place where the "project standard" is maintained, right? And that is/can be a "server", or is always a dev?

About changing servers: I'd wait on a decision until SF gets back on its feet, as with their server issues I'm not sure we can access everything in there ATM.
 
Last edited:

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
About changing servers: I'd wait on a decision until SF gets back on its feet, as with their server issues I'm not sure we can access everything in there ATM.
What is the important stuff that we don't have? I'm still hooked into the trunk so we have access to its contents. Besides, I just did a check in of a STS-1 in orbit scenario update I have had for a while with no issues.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
What is the important stuff that we don't have? I'm still hooked into the trunk so we have access to its contents.
The revision history.

Besides, I just did a check in of a STS-1 in orbit scenario update I have had for a while with no issues.
You better hold on to it, as it might still get lost. Some parts work, others don't.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
And the idea of using git as a "shell" for SVN, is it any good?

Given that you folks are not familiar with Git yet, I'd see this approach as adding just another layer of complexity. So I don't see it as a good idea. If you are concerned about history, this is no problem at all. Git has a good SVN facility to import old history into a new repo. I can assist with that process if you want to switch.

A question about git: it still needs a "head", a place where the "project standard" is maintained, right? And that is/can be a "server", or is always a dev?

No. You do not need a canonical central place. This is possible because content is not addressed by means of numbers or revisions - which would need a canonical place to hand out those numbers in a consistent way - but by means of hashing the content itself. In Git you do not refer to e.g. revision "r71", instead you talk about commit "ce104e".

With DVCS systems you can use a centralized workflow, but there is no need to do it so. You can also follow the "network of trust" workflow, where nobody pushes commits into a central repo, but instead maintainers pull from their lieutenants, and those in term accept so called "pull-requests" from other contributors. The later is what the Linux project uses.

What is the important stuff that we don't have?
The revision history.


You better hold on to it, as it might still get lost. Some parts work, others don't.

I've offered this the last time you had an SVN catastrophe, I can offer it again: your history is not lost, because I have closely followed the SSU development by means of a Mercurial repo. Every single commit is saved on my machine as well as in the Bitbucket cloud. If you need to rebuild it, I can make it public.
 
Last edited:

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
No. You do not need a canonical central place. This is possible because content is not addressed by means of numbers or revisions - which would need a canonical place to hand out those numbers in a consistent way - but by means of hashing the content itself. In Git you do not refer to e.g. revision "r71", instead you talk about commit "ce104e".
The hash as ID instead of a number is one thing I cannot put a "positive spin" on: SSU_V5.0Rce104e.zip just doesn't roll out of the tongue as SSU_v5.0r2971.zip... yes, I'm nitpicking. :lol:


With DVCS systems you can use a centralized workflow, but there is no need to do it so. You can also follow the "network of trust" workflow, where nobody pushes commits into a central repo, but instead maintainers pull from their lieutenants, and those in term accept so called "pull-requests" from other contributors. The later is what the Linux project uses.
I'd prefer we can keep the centralized workflow... no point using the mafia hierachy when there are only 2 people commiting. Each dev can have their private branches, and we keep the public ones as is for "cooperative work" and/or backup*, and we keep the trunk (or master as it is be called, right?) as the main line.

*) if I create a private branch, it isn't backed up to anywhere, right? Only the the files that I push get sent to others?


I'm about 90% convinced by git... is there a client to maybe start playing with it?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
The hash as ID instead of a number is one thing I cannot put a "positive spin" on: SSU_V5.0Rce104e.zip just doesn't roll out of the tongue as SSU_v5.0r2971.zip...

Well, to me both look about the same. The only difference is this: the "ce104e" will clearly indicate a specific status of the whole project in the DVCS system, no matter what copy of it I encounter in the world. The "2971" is a number that was given from one specific server, and if for whatever reason there are 2 servers, I can't reference a specific status of the whole project anymore without also knowing which server it originated from. In addition, 2971 gives a false metric of pretending to be "newer" than 2970, which it not necessarily is, not even in SVN.

But yeah... nitpicking.

I'd prefer we can keep the centralized workflow... no point using the mafia hierachy when there are only 2 people commiting. Each dev can have their private branches, and we keep the public ones as is for "cooperative work" and/or backup*, and we keep the trunk (or master as it is be called, right?) as the main line.

You can call your branches whatever you want in Git. Even "trunk" would be OK, although that terminology would confuse people coming to the project (and they will once you are hosting it in Git on e.g. Github).

*) if I create a private branch, it isn't backed up to anywhere, right? Only the the files that I push get sent to others?

Don't confuse files and commits. Imagine Git as automated ZIP workflow, like depicted in my blog entry here: https://www.orbiter-forum.com/blog.php?b=1161 . You never handle single files there, but whole project work status. What you exchange is these work status, not certain files. With a commit, you establish a specific work status, which can incorporate many file changes. All your commits are at first done locally, with no backup done anywhere, just like if you were doing ZIP archives all the time. With the push/pull operation, you transfer these commits to other copies of the repo, presumably a "blessed" one. You can control which commits you transfer (those made on "public" branches) and which commits you want to keep for yourself (those made on "private" branches). You can even transfer different sets on communicating with the "blessed" repo vs. developer repos (e.g. your own private cloud copy of the project).

I'm about 90% convinced by git... is there a client to maybe start playing with it?

Today there is a multitude of good clients, both command-line and GUI. There are good Visual-Studio integrations that you can install via on-board extension management. There are stand-alone tools like e.g. SourceTree . There are Explorer integrations like TortoiseGit. In general, look here for Git clients: https://git-scm.com/downloads/guis .

Personally, I prefer the command-line if it comes to Git, but then I'm not a good example because I primarily work with Mercurial.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Don't confuse files and commits. Imagine Git as automated ZIP workflow, like depicted in my blog entry here: https://www.orbiter-forum.com/blog.php?b=1161 . You never handle single files there, but whole project work status. What you exchange is these work status, not certain files. With a commit, you establish a specific work status, which can incorporate many file changes. All your commits are at first done locally, with no backup done anywhere, just like if you were doing ZIP archives all the time. With the push/pull operation, you transfer these commits to other copies of the repo, presumably a "blessed" one. You can control which commits you transfer (those made on "public" branches) and which commits you want to keep for yourself (those made on "private" branches). You can even transfer different sets on communicating with the "blessed" repo vs. developer repos (e.g. your own private cloud copy of the project).
This confirms was I was thinking. In terms of backup, a private branch is dependent on the dev, while a public branch... well is public, so everyone gets a copy.

What about write access to that "blessed" repo? Is it still limited as SVN?


Today there is a multitude of good clients, both command-line and GUI. There are good Visual-Studio integrations that you can install via on-board extension management. There are stand-alone tools like e.g. SourceTree . There are Explorer integrations like TortoiseGit. In general, look here for Git clients: https://git-scm.com/downloads/guis .

Personally, I prefer the command-line if it comes to Git, but then I'm not a good example because I primarily work with Mercurial.
VS extensions... VS is slow enough for me as it is, so I'll pass on those. CLI uses my keyboard too much :lol:, so I'll take a look at the GUIs, thanks!
 

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 confirms was I was thinking. In terms of backup, a private branch is dependent on the dev, while a public branch... well is public, so everyone gets a copy.

Your definition of public and private branch is not so strict in Git. In fact it does not distinguish on this property per se. Let's make an example:
* Imagine SSU is maintained in Git, with a cloud copy on the platform Github. The copy on Github has only one branch, the "master".
* People new to the project clone the Github repo, thereby creating a copy on their machines.
* Dev A creates a "work" branch on his machine, which he never pushes to the Github repo. He just merges his commits into the "master" branch (also on his machine) and pushes those commits to Github.
* Dev B does the same. He also has a "work" branch, but this is nothing like the one of A.
* Up to this point you can say the whole community has 3 branches: 1 "public" master, 1 "private" DevA/work, and 1 "private" DevB/work.
* But Git also allows for devs to share their branches. All they have to do is either to push the commits to the server and pull it from there, or simply exchange them directly. I.e. Dev A wants to show his work to B without commiting it to master yet. So he simply pushes his "work" branch to B, or B can pull the "work" branch into his own repo. The name conflict is resolved automatically by Git by means of prefixing the names with the so-called "remote" name. Let's say B calls the address of A's repo "DevA", then A's "work" branch will be visible in B's repo under the name "DevA/work".
* So now the simple public/private property falls apart. There are only branches that either are visible in a copy or not. Github has only "master", A has "master" and "work", B has "master", "work" and "DevA/work".

What about write access to that "blessed" repo? Is it still limited as SVN?

Write access in SVN is best compared with push access in Git. Whoever hosts the blessed repo can also control who has push and/or pull access.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
SourceTree ask for some needless account, so sayonara to that one.
TortoiseGit gives some error (apparently Cygwin's fault) and I can't download SSU.... :facepalm:
On to the 2º reboot of the day... SVN never looked better.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
SourceTree ask for some needless account, so sayonara to that one.
TortoiseGit gives some error (apparently Cygwin's fault) and I can't download SSU.... :facepalm:
On to the 2º reboot of the day... SVN never looked better.

Well, if you tried to download from the SSU SVN server via a Git client, you will probably fail.

SourceTree needing an account perhaps escaped my view due to me already having one with the Bitbucket one. Or perhaps they did not need it years ago when I actually tried it out.
 

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, if you tried to download from the SSU SVN server via a Git client, you will probably fail.
I was trying to use git as a shell for SVN (an option in TortoiseGit), to try things on my end. :shrug:

SourceTree needing an account perhaps escaped my view due to me already having one with the Bitbucket one. Or perhaps they did not need it years ago when I actually tried it out.
In no way am I blaming you. :cheers:
 

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 was trying to use git as a shell for SVN (an option in TortoiseGit), to try things on my end.

As I wrote, I think this mode is only adding complexity. If you want to try Git already with the SSU code-base, I'd suggest starting with a converted repo, not with the somewhat icky SVN-to-Git bridge.
If you folks want to switch, I can assist in doing the convert. I'll not do the work for a quick "look-and-meh", 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
The quick look (just in my computer) is what I was aiming for, so I could make a decision on my end.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
The quick look (just in my computer) is what I was aiming for, so I could make a decision on my end.

Then I would start with a simple repo first. Initialize, adding of files, commit, push, pull, checkout. There are also many tutorials out there that demonstrates the interaction. This is a nice one: https://try.github.io .

If you don't get yourself familiar with the paradigm change, your decision will suffer from the Blub paradox. I don't think that a quick look will suffice.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Official response to other SF project:
Hello,

On Tuesday, April 10th between 00:40 UTC and 17:38 UTC, SourceForge experienced a filesystem failure that affected a limited number of svn commits, causing them not to be saved. We resolved the issue as soon as we became aware of it, but commits from a small number of projects, including yours, were affected. Everything should be ok from now on.

Sincerely,

SourceForge Support

I'm trying the merge for the 674th time (no, really) to see if SSU is also fixed... but I'm not holding my breath as their SVN issue predates April 10th.

---------- Post added at 10:28 PM ---------- Previous post was at 10:18 PM ----------

Surprise surprise... :facepalm:
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Official response to other SF project:


I'm trying the merge for the 674th time (no, really) to see if SSU is also fixed... but I'm not holding my breath as their SVN issue predates April 10th.

---------- Post added at 10:28 PM ---------- Previous post was at 10:18 PM ----------

Surprise surprise... :facepalm:
Where do we stand on this SVN aspect? I have noticed a few issues with the orbiter mesh and I'd like to check in the fixed version.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Where do we stand on this SVN aspect? I have noticed a few issues with the orbiter mesh and I'd like to check in the fixed version.

Still little progress: yesterday the guy asked to check if it worked... and it didn't. :facepalm: I even updated to the latest version of TortoiseSVN and nothing changed.
There are people with issues since the move to the "new server", about 2 months ago, and are still waiting... :facepalm: :facepalm:
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Still little progress: yesterday the guy asked to check if it worked... and it didn't. :facepalm: I even updated to the latest version of TortoiseSVN and nothing changed.
There are people with issues since the move to the "new server", about 2 months ago, and are still waiting... :facepalm: :facepalm:
Maybe I should make an official request to Xyon about some space on the O-F servers as temporary measure? Is the repo history really that important? Sure, we have to start from 0 again, but maybe it's worth transitioning away from S-F? That includes our ticket list, those could easily be recreated here on O-F.
 
Status
Not open for further replies.
Top