Board index FlightGear The FlightGear project

FGAddon vs. FGMEMBERS, bus factors etc.

Questions about the FlightGear organisation, website, wiki etc.

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby bugman » Thu May 07, 2015 10:08 am

IAHM-COL wrote in Wed May 06, 2015 10:42 pm:
https://git.wiki.kernel.org/index.php/GitSvnComparison wrote:


You should note that this source is likely to be quite biased towards git, considering it is a git wiki page. It is often used as a propaganda piece, disguised as a non-biased analysis, for converting subversions users to git. It has been presented to me many, many times over the last decade and a half. But I use both svn and git regularly, so I find it quite an amusing read. There are some real gems of misinformation in there. I especially like git's advantage of "Git branches carry their entire history". That one always makes me smile :) Just run 'svn log' on a subversion branch and watch what happens ;)
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby IAHM-COL » Thu May 07, 2015 4:39 pm

bugman wrote in Thu May 07, 2015 8:25 am:Hi Israel,

Subversion is one tool of many, and it gets the job done efficiently, just like git.

Regards,

Edward



Dear Ed.
Yes. Ive read of all your experience and expertise in SCMs. That's great! I happen to be a rather incompetent user of git, and a total ignorant when it comes to Subversion: so that's the "Naked Truth".
I understand that some of the resources I quoted may be git-biased. But still, I found that a bit preferable over your opinion without quoted resources. I had try to do a google biased search "SVN is better at branching", with no success:: basically all information I gather points to the fact that branches in subversion are just copies upon which the user applies the "meaning" of a branch.

In the git perspective, that is a very poor solution. Everyone can make a "copy", but that is not what a "branch" actually mean in the git flow. As some of my quotes indicated, it has to do with flagging files.

Branches being copies; this have profound impacts, as an example, in the repository size, if you decide to be very liberal upon branching. In git, creating a branch for an aircraft does not automatically double the size of it.

On this respect, and upon revising this "branching behavior" I stumble upon an additional criticism of the monolithic SVN FGAddon subversion repository. One criticism that I guess will not be very kindly received by the upper management:

Currently, branches are created to manage "release" of the aircraft, such as 3.4, and it is expected to be done upon following releases such as 3.6 etc
http://sourceforge.net/p/flightgear/fga ... ase-3.4.0/

Creating this branch effectively doubled the repository size, since a "copy" of all aircraft was created! (?)
And everytime we/they/FG were to do it a new copy will be made ! (?)

So in the current situation the repository size scalates on a lineal function on N=number of releases, which for a repository of about 28GB of content is a rather considerable scalation. Example upon 5 releases, we will already find an scalation of 28*5=140GB.
If you/we/FG were to now also begin to make "versioning" branching over individual aircraft, then scalation can go exponential growth, as opposed to lineal growth for each of the aircraft versioned in this manner.

I know I may sound a bit harsh with the svn branching mechanism of "copying" but I am just trying to avoid the pitfall of SNAFU (per the cathedral and Bazaar book)

http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s14.html wrote:The peer-to-peer part is essential to the community's astonishing productivity. The point Kropotkin was trying to make about power relationships is developed further by the `SNAFU Principle': ``True communication is possible only between equals, because inferiors are more consistently rewarded for telling their superiors pleasant lies than for telling the truth.'' Creative teamwork utterly depends on true communication and is thus very seriously hindered by the presence of power relationships. The open-source community, effectively free of such power relationships, is teaching us by contrast how dreadfully much they cost in bugs, in lowered productivity, and in lost opportunities.

Further, the SNAFU principle predicts in authoritarian organizations a progressive disconnect between decision-makers and reality, as more and more of the input to those who decide tends to become pleasant lies. The way this plays out in conventional software development is easy to see; there are strong incentives for the inferiors to hide, ignore, and minimize problems. When this process becomes product, software is a disaster.
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby bugman » Thu May 07, 2015 5:08 pm

Hi Israel,

I would like to illustrate this with a very simple and repeatable example:

Code: Select all
[edward@localhost svn_size_test]$ svnadmin create repo
[edward@localhost svn_size_test]$ svn co file://$PWD/repo/ copy
Checked out revision 0.
[edward@localhost svn_size_test]$ cd copy/
[edward@localhost copy]$ mkdir tags branches trunk
[edward@localhost copy]$ svn add *
A         branches
A         tags
A         trunk
[edward@localhost copy]$ svn ci -m "Created the base directories."
Adding         branches
Adding         tags
Adding         trunk
[edward@localhost copy]$ cd trunk; cp ~/debian-7.8.0-amd64-DVD-1.iso .
[edward@localhost copy]$ svn add debian-7.8.0-amd64-DVD-1.iso
A  (bin)  debian-7.8.0-amd64-DVD-1.iso
[edward@localhost trunk]$ svn ci -m "Added a large ISO image."
Adding  (bin)  debian-7.8.0-amd64-DVD-1.iso
Transmitting file data .
Committed revision 2.
[edward@localhost trunk]$ cd ../..
[edward@localhost svn_size_test]$ du -ch --max-depth=1
3.7G    ./repo
7.4G    ./copy
12G     .
12G     total
[edward@localhost svn_size_test]$ cd copy/
[edward@localhost copy]$ svn cp trunk branches/iso_test_branch
A         branches/iso_test_branch
[edward@localhost copy]$ svn ci -m "Creating a size testing branch."
Adding         branches/iso_test_branch
Adding  (bin)  branches/iso_test_branch/debian-7.8.0-amd64-DVD-1.iso

Committed revision 3.
[edward@localhost copy]$ cd ..
[edward@localhost svn_size_test]$ du -ch --max-depth=1
3.7G    ./repo
12G     ./copy
15G     .
15G     total
[edward@localhost svn_size_test]$


As you can see, the repository size does not change when copying this huge ISO file. With subversion you would never check out the entire repository, as in this 'copy' directory example, so there is no problem that the local copy becomes too large (if it does, then it is a sign that you are doing something wrong).

I would also like to quote the svn manual, specifically about cheap copies

http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create wrote:Cheap Copies

Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects.

This is why you'll often hear Subversion users talk about “cheap copies.” It doesn't matter how large the directory is—it takes a very tiny, constant amount of time and space to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a “cheap copy” of the previous revision, with a few items lazily changed within. (To read more about this, visit Subversion's web site and read about the “bubble up” method in Subversion's design documents.)

Of course, these internal mechanics of copying and sharing data are hidden from the user, who simply sees copies of trees. The main point here is that copies are cheap, both in time and in space. If you create a branch entirely within the repository (by running svn copy URL1 URL2), it's a quick, constant-time operation. Make branches as often as you want.


So there is no need to worry about repository size. Subversion is all about "cheap copies".

Regards,

Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby IAHM-COL » Thu May 07, 2015 5:16 pm

makes sense now
Thanks Ed.

It duplicates data only when it is necessary to disambiguate different versions of objects.

Here it pairs upon the git behavior quite well, too. Just two different ways to solve the same problem.
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby onox » Thu May 07, 2015 8:16 pm

bugman wrote in Thu May 07, 2015 10:08 am:Just run 'svn log' on a subversion branch and watch what happens ;)


I get this:

Code: Select all
svn: E000110: Unable to connect to a repository at URL 'svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Lockheed1049h'
svn: E000110: Unknown hostname 'svn.code.sf.net'


bugman wrote in Thu May 07, 2015 8:25 am:As it says, you copy with 'svn cp' what you would like to make a branch of. As you can copy anything, you can branch anything.


How do you know in advance which files you need to copy? So if you're in an IDE and you want to make some changes, you first need to do svn cp before you can start editing a file? Instead of directly start editing any file because you have switched to a new branch with git?
onox
Retired
 
Posts: 431
Joined: Fri Jun 20, 2014 3:45 pm

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby bugman » Thu May 07, 2015 9:21 pm

onox wrote in Thu May 07, 2015 8:16 pm:
bugman wrote in Thu May 07, 2015 10:08 am:Just run 'svn log' on a subversion branch and watch what happens ;)


I get this:

Code: Select all
svn: E000110: Unable to connect to a repository at URL 'svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Lockheed1049h'
svn: E000110: Unknown hostname 'svn.code.sf.net'


bugman wrote in Thu May 07, 2015 8:25 am:As it says, you copy with 'svn cp' what you would like to make a branch of. As you can copy anything, you can branch anything.


How do you know in advance which files you need to copy? So if you're in an IDE and you want to make some changes, you first need to do svn cp before you can start editing a file? Instead of directly start editing any file because you have switched to a new branch with git?


Just describe what you'd like to do. I'm not sure what the aim is, so I can't give a clear answer. I also just ran:

Code: Select all
svn log svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Lockheed1049h


and saw the full logs, so maybe the connection was down when you tried.
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby wkitty42 » Thu May 07, 2015 9:42 pm

bugman wrote in Thu May 07, 2015 9:21 pm:
Code: Select all
svn log svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Lockheed1049h


and saw the full logs, so maybe the connection was down when you tried.

confirmed that the given command works... i just tested it from here and the initial output is
Code: Select all
myuser@mymachine:~$ svn log svn://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/Lockheed1049h
------------------------------------------------------------------------
r647 | sanhozay | 2015-05-07 07:51:50 -0400 (Thu, 07 May 2015) | 5 lines

Lockheed1049h version 2.8.3: Checklist reformatting, refactoring and minor big fixes

  * Replace stray tabs with spaces
  * Fixes to marker positions and missing markers
  * Refactor duplicated Nasal code out of checklists
FWTW ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9148
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby onox » Thu May 07, 2015 10:42 pm

Of course the connection was down; I pulled the internet cable before doing svn log. Let me quote a bit more of your post:

bugman wrote in Thu May 07, 2015 10:08 am:I especially like git's advantage of "Git branches carry their entire history". That one always makes me smile :) Just run 'svn log' on a subversion branch and watch what happens ;)


...nothing unless you have a working internet connection.
onox
Retired
 
Posts: 431
Joined: Fri Jun 20, 2014 3:45 pm

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby bugman » Thu May 07, 2015 11:06 pm

onox wrote in Thu May 07, 2015 10:42 pm:Of course the connection was down; I pulled the internet cable before doing svn log. Let me quote a bit more of your post:

bugman wrote in Thu May 07, 2015 10:08 am:I especially like git's advantage of "Git branches carry their entire history". That one always makes me smile :) Just run 'svn log' on a subversion branch and watch what happens ;)


...nothing unless you have a working internet connection.


True, but that's usually not a problem. The meaning is that all repository data is stored locally for git vs. on the server for svn, but this can also be seen as an advantage for svn - i.e. less HD space required ;) It probably depends on if you value HD space more or having all history for when you loose connectivity. A disadvantage for one is an advantage for another. You can rebalance the scales using git-svn, but someone still needs to write a svn-git client to really confuse things.
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Jabberwocky » Fri May 08, 2015 9:52 pm

Well, bottom line for me is, I can work easily with the FGMEMBERs and if the FGADDON guys figure one day out how to get plaes from there they don't have ... feel free as far as my work is concerned. It is GPL, by all means and that means EVERYONE can copy it, expand on it, whatever. Because GPL doesn't include any clause like EVERYBODY but xxx, yyy and zzz because I don't like their noses. However, I preserve the right to determine to where I post my work which implicitly determines from where you can copy it. That's only fair.
Now back to my plane in work ...
Jabberwocky
Retired
 
Posts: 1316
Joined: Sat Mar 22, 2014 8:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Hooray » Sat May 09, 2015 2:17 am

Jabberwocky wrote in Fri May 08, 2015 9:52 pm:However, I preserve the right to determine to where I post my work which implicitly determines from where you can copy it. That's only fair.
Now back to my plane in work ...


which kinda proves the point of the whole discussion - simply because it is also up to you whether you are willing to maintain your work in other, 3rd party places/hangars, or not - as well as being your decision whether you want to collaborate with others using/re-using your work for other purposes, including possibly those that may compete/conflict with your own idea of future development, such as using a different FDM engine, different 3D model etc - or even making changes that may be/become incompatible with your own efforts, no matter that is in terms of code/XML or the infrastructure you're using, or the degree of end-user support you are willing to provide.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Jabberwocky » Sat May 09, 2015 2:41 am

Hooray ...

You shouldn't try to twist my words around, Hooray. The fact that you sometimes try manipulative games doesn't mean you are good at it ... actually you are rather embarrassing when you try.
Here is the point: I push my planes to FGMEMBERS. They are under GPL. Any other person including those who run any other repository, even under the fraudulent term of "being official" can copy them, distribute them, expand on them, paint them differently or build by me a flying laundromat from them. That is GPL. I can't and won't restrict this in any way because that would mean, my work isn't under GPL anymore. So either an author cklaims, his work is GPL or he doesn't. But there is no GPL saying "Everyone but those who cause a temper tantrum are excluded". However, GPL doesn't demand, that I have to send everyone who may want a part of my work a personalized copy. There is especially no clause in GPL, that I have to send copies to people, groups, organizations disguising as "official" for something who don't even want copies.

J.
Jabberwocky
Retired
 
Posts: 1316
Joined: Sat Mar 22, 2014 8:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: What/Where did you fly today? - Part 2

Postby chris_blues » Sun Sep 06, 2015 10:12 pm

Some posts was moved here from the topic What/Where did you fly today? - Part 2

I really don't want to go political now, but I feel I have to. So, please don't let this come to an argument about this (because I apreciate your response and pointers); but:
fgmembers is still a hostile fork of fgaddon, still not giving anything back to the FGcommunity (read fgaddon). We had this (bad) discussion on the devel list last year or so, which resulted in fgmembers. And all that happened is a pull from fgaddon and zero feedback from fgmembers.

So thanks for pointing me there, but no thanks! (please, no hard feelings, but I had to say this)
Last edited by Johan G on Mon Sep 07, 2015 3:53 pm, edited 1 time in total.
Reason: Some posts was moved here from the topic What/Where did you fly today? - Part 2
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian stable 64bit - i7 8x2.8GHz - 20GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian stable 64

Re: What/Where did you fly today? - Part 2

Postby legoboyvdlp » Sun Sep 06, 2015 11:11 pm

Would you not even use it to get these planes, not even to download via git but even for just .zip downloads, to join us in the Moranes and Avros and Maurice Farmans over France?
If not, I'm sure Lester can provide mediafire links!
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: What/Where did you fly today? - Part 2

Postby chris_blues » Sun Sep 06, 2015 11:44 pm

Well, I maybe would hesitantly get a plane there, but I'd much rather get it via fgaddon...
It's not an easy thing to see the community get split in two!
Don't hesitate to let me know if I'm incorrect or just annoying! As long as you do it gently! :)
Debian stable 64bit - i7 8x2.8GHz - 20GB RAM - GeForce GTS 450
Citation II
User avatar
chris_blues
Retired
 
Posts: 1577
Joined: Mon May 03, 2010 2:30 pm
Location: claws of real life
Callsign: chris_blues
Version: GIT
OS: Debian stable 64

PreviousNext

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 7 guests