UNBIASED FACTS: ? Bugzilla & R-devel Mailing Lists: Remain unchanged: Understood as Ticketing platforms for bug pull requests on the R-devel Git Repository. ? Git Repository Options: A) Github (Cloud with Automated backups from GitHub to CRAN Server): https://github.com B) Gitlab (Selfhosted on CRAN): https://about.gitlab.com C) Phabricator (Selfhosted on CRAN): https://www.phacility.com D) Microsoft Codeplex: https://www.codeplex.com E) Others: Unknown GOOGLE TRENDS: https://trends.google.com/trends/explore?date=all&q=Git,Svn,Github,Gitlab EXAMPLE Git Repository on Core Python: https://github.com/python PERSONAL OPINION / MOTIVATION: I think that moving efforts in this direction is important because it would allow a true Open Source Innovation & Open Collaboration in R between: * R Community. * And R-Core. For: * R Bug Fixes. * And Core Feature Wishlist. As anyone would be able to: * Check the unassigned bugs in Bugzilla (apart from R-Core). * And propose bugs fixes by themselves as Pull requests (by mentioning the Bug ID of Bugzilla or the Mailing Lists). This would allow that _individuals_ either from Universities or Companies interested in the Development of R: * apart of donating economical resources to the R Foundation. * could help to maintain core R Code by themselves. Which aligns with the true spirit of R, which shall be done from contributing individuals, for individuals themselves. It would also allow to put the focus on the precise lines of code changed with each Commit, and revert changes in an easy way, without verbose E-mails: Tidy, Clean, Maintainable, and Fast. At last, I noticed R-devel Archives do not have an E-mail Id (Unique Unsigned Integer), so it would be a good idea to add one for pull requests if Git was adopted. Juan [[alternative HTML version deleted]]
Mark van der Loo
2018-Jan-04 10:06 UTC
[Rd] Community Feedback: Git Repository for R-Devel
This question has been discussed before on this list: http://r.789695.n4.nabble.com/Why-R-project-source-code-is-not-on-Github-td4695779.html See especially Jeroen's answer. Best, Mark Op do 4 jan. 2018 om 01:11 schreef Juan Telleria <jtelleriar at gmail.com>:> UNBIASED FACTS: > ? Bugzilla & R-devel Mailing Lists: Remain unchanged: Understood as > Ticketing platforms for bug pull requests on the R-devel Git Repository. > > ? Git Repository Options: > A) Github (Cloud with Automated backups from GitHub to CRAN Server): > https://github.com > B) Gitlab (Selfhosted on CRAN): https://about.gitlab.com > C) Phabricator (Selfhosted on CRAN): https://www.phacility.com > D) Microsoft Codeplex: https://www.codeplex.com > E) Others: Unknown > > GOOGLE TRENDS: > https://trends.google.com/trends/explore?date=all&q=Git,Svn,Github,Gitlab > > EXAMPLE > Git Repository on Core Python: https://github.com/python > > PERSONAL OPINION / MOTIVATION: > I think that moving efforts in this direction is important because it would > allow a true Open Source Innovation & Open Collaboration in R between: > * R Community. > * And R-Core. > For: > * R Bug Fixes. > * And Core Feature Wishlist. > As anyone would be able to: > * Check the unassigned bugs in Bugzilla (apart from R-Core). > * And propose bugs fixes by themselves as Pull requests (by mentioning the > Bug ID of Bugzilla or the Mailing Lists). > > This would allow that _individuals_ either from Universities or Companies > interested in the Development of R: > * apart of donating economical resources to the R Foundation. > * could help to maintain core R Code by themselves. > Which aligns with the true spirit of R, which shall be done from > contributing individuals, for individuals themselves. > > It would also allow to put the focus on the precise lines of code changed > with each Commit, and revert changes in an easy way, without verbose > E-mails: Tidy, Clean, Maintainable, and Fast. > > At last, I noticed R-devel Archives do not have an E-mail Id (Unique > Unsigned Integer), so it would be a good idea to add one for pull requests > if Git was adopted. > > Juan > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel[[alternative HTML version deleted]]
Thank you Mark, this is what I was looking for. On Sunday I will read again in detail previous discussion's facts, and attach the pros and cons here, so that they remain for the future, and the topic can be closed. Juan El 4 ene. 2018 11:06 a. m., "Mark van der Loo" <mark.vanderloo at gmail.com> escribi?:> This question has been discussed before on this list: > http://r.789695.n4.nabble.com/Why-R-project-source-code-is- > not-on-Github-td4695779.html > > See especially Jeroen's answer. > > Best, > Mark > > Op do 4 jan. 2018 om 01:11 schreef Juan Telleria <jtelleriar at gmail.com>: > >> UNBIASED FACTS: >> ? Bugzilla & R-devel Mailing Lists: Remain unchanged: Understood as >> Ticketing platforms for bug pull requests on the R-devel Git Repository. >> >> ? Git Repository Options: >> A) Github (Cloud with Automated backups from GitHub to CRAN Server): >> https://github.com >> B) Gitlab (Selfhosted on CRAN): https://about.gitlab.com >> C) Phabricator (Selfhosted on CRAN): https://www.phacility.com >> D) Microsoft Codeplex: https://www.codeplex.com >> E) Others: Unknown >> >> GOOGLE TRENDS: >> https://trends.google.com/trends/explore?date=all&q=Git,Svn,Github,Gitlab >> >> EXAMPLE >> Git Repository on Core Python: https://github.com/python >> >> PERSONAL OPINION / MOTIVATION: >> I think that moving efforts in this direction is important because it >> would >> allow a true Open Source Innovation & Open Collaboration in R between: >> * R Community. >> * And R-Core. >> For: >> * R Bug Fixes. >> * And Core Feature Wishlist. >> As anyone would be able to: >> * Check the unassigned bugs in Bugzilla (apart from R-Core). >> * And propose bugs fixes by themselves as Pull requests (by mentioning the >> Bug ID of Bugzilla or the Mailing Lists). >> >> This would allow that _individuals_ either from Universities or Companies >> interested in the Development of R: >> * apart of donating economical resources to the R Foundation. >> * could help to maintain core R Code by themselves. >> Which aligns with the true spirit of R, which shall be done from >> contributing individuals, for individuals themselves. >> >> It would also allow to put the focus on the precise lines of code changed >> with each Commit, and revert changes in an easy way, without verbose >> E-mails: Tidy, Clean, Maintainable, and Fast. >> >> At last, I noticed R-devel Archives do not have an E-mail Id (Unique >> Unsigned Integer), so it would be a good idea to add one for pull requests >> if Git was adopted. >> >> Juan >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > >[[alternative HTML version deleted]]
I attach a basic State of Art: ########################################################################################################################################## # State of Art Analysis of Git vs SVN ########################################################################################################################################## Scopus Keywords: GIT AND SVN ########################################################################################################################################## # 1. How Do Centralized (SVN) and Distributed Version Control (GIT) Systems Impact Software Changes? (22 Citations; Published: 2014) ########################################################################################################################################## 1.1 Paper Conclusions We found that the use of CVCS and DVCS have observable effects on developers, teams and processes. The most surprising findings are that (i) the size of commits in DVCS was smaller than in CVCS, (ii) developers split commits (group changes by intent) more often in DVCS, and (iii) DVCS commits are more likely to reference issue tracking labels. These show that DVCS contain higher quality commits compared to CVCS due to their smaller size, cohesive changes and the presence of issue tracking labels. The survey provided valuable information on why developers prefer one paradigm versus the other. DVCS are preferred because of killer features, such as the ability of committing locally. In contrast CVCS are preferred for their ease of use and faster learning curve. 1.2 Full Paper http://dig.cs.illinois.edu/papers/ICSE14_Caius.pdf ########################################################################################################################################## # 2 Version Control with Git (Book: J Loeliger, M McCullough ? 2012) ########################################################################################################################################## 2.1 Book Introduction ***The Birth of Git*** Often, when there is discord between a tool and a project, the developers simply create a new tool. Indeed, in the world of software, the temptation to create new tools can be deceptively easy and inviting. In the face of many existing version control systems, the decision to create another shouldn?t be made casually. However, given a critical need, a bit of insight, and a healthy dose of motivation, forging a new tool can be exactly the right course. Git, affectionately termed ?the information manager from hell? by its creator is such a tool. Although the precise circumstances and timing of its genesis are shrouded in political wrangling within the Linux Kernel community, there is no doubt that what came from that fire is a well-engineered version control system capable of supporting worldwide development of software on a large scale. Prior to Git, the Linux Kernel was developed using the commercial BitKeeper VCS, which provided sophisticated operations not available in then-current, free software version control systems such as RCS and CVS. However, when the company that owned BitKeeper placed additional restrictions on its ?free as in beer? version in the spring of 2005, the Linux community realized that BitKeeper was no longer a viable solution. Linus looked for alternatives. Eschewing commercial solutions, he studied the free software packages but found the same limitations and flaws that led him to reject them previously. What was wrong with the existing VCS systems? What were the elusive missing features or characteristics that Linus wanted and couldn?t find? ***Facilitate distributed development*** There are many facets to ?distributed development,? and Linus wanted a new VCS that would cover most of them. It had to allow parallel as well as independent and simultaneous development in private repositories without the need for constant synchronization with a central repository, which could form a development bottleneck. It had to allow multiple developers in multiple locations even if some of them were offline temporarily. ***Scale to handle thousands of developers*** It isn?t enough just to have a distributed development model. Linus knew that thousands of developers contribute to each Linux release, so any new VCS had to handle a very large number of developers, whether they were working on the same or on different parts of a common project. And the new VCS had to be able to integrate all of their work reliably. ***Perform quickly and efficiently*** Linus was determined to ensure that a new VCS was fast and efficient. In order to support the sheer volume of update operations that would be made on the Linux Kernel alone, he knew that both individual update operations and network transfer operations would have to be very fast. To save space and thus transfer time, compression and ?delta? techniques would be needed. Using a distributed model instead of a centralized model also ensured that network latency would not hinder daily development. ***Maintain integrity and trust*** Because Git is a distributed revision control system, it is vital to obtain absolute assurance that data integrity is maintained and is not somehow being altered. How do you know the data hasn?t been altered in transition from one developer to the next, or from one repository to the next? For that matter, how do you know that the data in a Git repository is even what it purports to be? Git uses a common cryptographic hash function, called Secure Hash Function (SHA1), to name and identify objects within its database. Although perhaps not absolute, in practice it has proven to be solid enough to ensure integrity and trust for all of Git?s distributed repositories. ***Enforce accountability*** One of the key aspects of a version control system is knowing who changed files, and if at all possible, why. Git enforces a change log on every commit that changes a file. The information stored in that change log is left up to the developer, project requirements, management, convention, etc. Git ensures that changes will not happen mysteriously to files under version control because there is an accountability trail for all changes. ***Immutability*** Git?s repository database contains data objects that are immutable. That is, once they have been created and placed in the database, they cannot be modified. They can be recreated differently, of course, but the original data cannot be altered without consequences. The design of the Git database means that the entire history stored within the version control database is also immutable. Using immutable objects has several advantages, including very quick comparison for equality. ***Atomic transactions*** With atomic transactions, a number of different but related changes are performed either all together or not at all. This property ensures that the version control database is not left in a partially changed (and hence possibly corrupted) state while an update or commit is happening. Git implements atomic transactions by recording complete, discrete repository states that cannot be broken down into individual or smaller state changes. ***Support and encourage branched development*** Almost all VCSs can name different genealogies of development within a single project. For instance, one sequence of code changes could be called ?development? while another is referred to as ?test.? Each version control system can also split a single line of development into multiple lines and then unify, or merge, the disparate threads. As with most VCSs, Git calls a line of development a branch and assigns each branch a name. Along with branching comes merging. Just as Linus wanted easy branching to foster alternate lines of development, he also wanted to facilitate easy merging of those branches. Because branch merging has often been a painful and difficult operation in version control systems, it would be essential to support clean, fast, easy merging. ***Complete repositories*** So that individual developers needn?t query a centralized repository server for historical revision information, it was essential that each repository have a complete copy of all historical revisions of every file. ***A clean internal design*** Even though end users might not be concerned about a clean internal design, it was important to Linus and ultimately to other Git developers as well. Git?s object model has simple structures that capture fundamental concepts for raw data, directory structure, recording changes, etc. Coupling the object model with a globally unique identifier technique allowed a very clean data model that could be managed in a distributed development environment. ***Be free, as in freedom*** ?Nuff said. Given a clean slate to create a new VCS, many talented software engineers collaborated and Git was born. Necessity was the mother of invention again! 1.2.2 Book Link https://books.google.es/books?hl=en&lr=&id=aM7-Oxo3qdQC&oi=fnd&pg=PR3&dq=GIT+SVN&ots=39uhIKPlpc&sig=PmxABWMem-h4Fp1-JR-4C2HTwUY&redir_esc=y#v=onepage&q=GIT%20SVN&f=false Chapter 18: ?Using Git with Subversion Repositories?, is of special interest. You can find the full book accessible with a basic search in Google: ?Version Control with Git? filetype:pdf Juan [[alternative HTML version deleted]]