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