SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]
- Thread starter DaveS
- Start date
- Status
GLS
Well-known member
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:
GLS
Well-known member
The revision history.
You better hold on to it, as it might still get lost. Some parts work, others don't.
Face
Well-known member
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.
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.
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
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:
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
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.
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).
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).
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
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?
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
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".
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
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.
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
GLS
Well-known member
I was trying to use git as a shell for SVN (an option in TortoiseGit), to try things on my end. :shrug:
In no way am I blaming you.
Face
Well-known member
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
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
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
About a little discovery I made: https://www.orbiter-forum.com/showthread.php?p=575091&postcount=475
A while back I hacked a fix so we could launch to a 28.45º orbit by making a dog-leg late in the ascent, but was never happy about it.... now I know the source of the issue.
A while back I hacked a fix so we could launch to a 28.45º orbit by making a dog-leg late in the ascent, but was never happy about it.... now I know the source of the issue.
GLS
Well-known member
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:
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:
GLS
Well-known member
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
Similar threads
