SSU Development thread (4.0 to 5.0) - Page 101 - Orbiter-Forum

DaveS · 04-11-2018, 09:06 PM

Quote:

Originally Posted by GLS

And the idea of using git as a "shell" for SVN, is it any good?

BTW: page 100

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 · 04-11-2018, 09:24 PM

Quote:

Originally Posted by DaveS

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.

DaveS · 04-11-2018, 09:42 PM

Quote:

Originally Posted by GLS

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 · 04-11-2018, 09:46 PM

Quote:

Originally Posted by DaveS

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.

Quote:

Originally Posted by DaveS

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** · 04-12-2018, 06:47 AM

Quote:

Originally Posted by GLS

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.

Quote:

Originally Posted by GLS

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.

Quote:

Originally Posted by DaveS

What is the important stuff that we don't have?

Quote:

Originally Posted by GLS

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.

GLS · 04-12-2018, 09:46 AM

Quote:

Originally Posted by Face

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.

Quote:

Originally Posted by Face

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** · 04-12-2018, 10:48 AM

Quote:

Originally Posted by GLS

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.

Quote:

Originally Posted by GLS

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).

Quote:

Originally Posted by GLS

*) 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).

Quote:

Originally Posted by GLS

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 · 04-12-2018, 11:05 AM

Quote:

Originally Posted by Face

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?

Quote:

Originally Posted by Face

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

, so I'll take a look at the GUIs, thanks!

**Face** · 04-12-2018, 11:33 AM

Quote:

Originally Posted by GLS

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".

Quote:

Originally Posted by GLS

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 · 04-12-2018, 03:54 PM

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....

On to the 2º reboot of the day... SVN never looked better.

**Face** · 04-12-2018, 04:24 PM

Quote:

Originally Posted by GLS

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....

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 · 04-12-2018, 04:41 PM

Quote:

Originally Posted by Face

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.

Quote:

Originally Posted by Face

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.

**Face** · 04-12-2018, 04:50 PM

Quote:

Originally Posted by GLS

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 · 04-12-2018, 04:56 PM

The quick look (just in my computer) is what I was aiming for, so I could make a decision on my end.

**Face** · 04-12-2018, 05:07 PM

Quote:

Originally Posted by GLS

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.

04-11-2018, 09:24 PM	#1502
GLS Addon Developer	Quote: Originally Posted by DaveS 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 by GLS; 04-11-2018 at 09:26 PM.

04-12-2018, 06:47 AM	#1505
Face Beta Tester	Quote: Originally Posted by GLS 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. Quote: Originally Posted by GLS 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. Quote: Originally Posted by DaveS What is the important stuff that we don't have? Quote: Originally Posted by GLS 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 by Face; 04-12-2018 at 07:18 AM. Reason: typo

Quick Links	Need Help?
About Us Register to Participate Orbiter Website Orbiter Download Projects Recommended Addons Orbit Hangar Mods Photo Gallery Social Groups External Links	Did you forget your password? Rules & Guidelines Frequently Asked Questions Orbiter F.A.Q. Orbiter Tutorials Orbiter IRC Chat Search Forum Site Map Contact Us Mark Forums Read

04-11-2018, 09:06 PM	#1501
DaveS Addon Developer	Quote: Originally Posted by GLS And the idea of using git as a "shell" for SVN, is it any good? BTW: page 100 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?

04-11-2018, 09:42 PM	#1503
DaveS Addon Developer	Quote: Originally Posted by GLS 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.

04-11-2018, 09:46 PM	#1504
GLS Addon Developer	Quote: Originally Posted by DaveS 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. Quote: Originally Posted by DaveS 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.

04-12-2018, 09:46 AM	#1506
GLS Addon Developer	Quote: Originally Posted by Face 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. Quote: Originally Posted by Face 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?

04-12-2018, 10:48 AM	#1507
Face Beta Tester	Quote: Originally Posted by GLS 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. Quote: Originally Posted by GLS 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). Quote: Originally Posted by GLS* ) 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). Quote: Originally Posted by GLS* 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.

04-12-2018, 11:05 AM	#1508
GLS Addon Developer	Quote: Originally Posted by Face 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? Quote: Originally Posted by Face 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 , so I'll take a look at the GUIs, thanks!

04-12-2018, 11:33 AM	#1509
Face Beta Tester	Quote: Originally Posted by GLS 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". Quote: Originally Posted by GLS 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.

04-12-2018, 03:54 PM	#1510
GLS Addon Developer	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.... On to the 2º reboot of the day... SVN never looked better.

04-12-2018, 04:24 PM	#1511
Face Beta Tester	Quote: Originally Posted by GLS 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.... 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.

04-12-2018, 04:41 PM	#1512
GLS Addon Developer	Quote: Originally Posted by Face 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. Quote: Originally Posted by Face 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.

04-12-2018, 04:50 PM	#1513
Face Beta Tester	Quote: Originally Posted by GLS 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.

04-12-2018, 04:56 PM	#1514
GLS Addon Developer	The quick look (just in my computer) is what I was aiming for, so I could make a decision on my end.

04-12-2018, 05:07 PM	#1515
Face Beta Tester	Quote: Originally Posted by GLS 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.