Re: Proposal: Switch back to savannah using GIT

[Dr. H. Nikolaus Schaller]

Am 25.05.2015 um 15:26 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:

> Hi,
> 
> (sorry for some horrid to-posting, but I do not reply 1:1 here)
> 
> I'm in favor of moving back to savannah again, but not the switch to GIT.
> 
> Every VCS system has its pros and cons and we can debate forever. The main 
> point is, however, what I would borrow from OpenBSD's reasoning: do not 
> switch system every couple of years, just because something is a "trend".
> 
> SVN is a fine tool and I see no particular limitations, the first versions 
> were atrocious, but now it settled down
> Saying that it is little maintained, is a moot argument: I actually expect a 
> versioning tool to stabilize. SVN is not unmaintained either:
> Stable release    1.8.13 (March 31, 2015; 47 days ago)
> Preview release    1.9.0-beta1 (March 18, 2015; 60 days ago)
> 
> You need many tools to support a system when the system is weak, otherwise 
> you can use the tool itself.
> 
> Given the general "war", I found around some "useful" support for SVN: I 
> gathered/grouped here some. They are not all my opinion, but I endorse them
> 
> 1. SVN supports empty directories
> 2. SVN can check out/clone a sub-tree, preferred to submodules
>   (svn:external has more power and flexibility than submodules)
>    1. Repository layout. You can have an umbrella project and
>       subprojects and choose what to check out when.
> 3. SVN supports exclusive access control|svn lock|which is useful for
>   hard-to-merge files (cited several times for difficult merges)
> 4. SVN supports binary files and large files more easily (and doesn't
>   require copying old versions everywhere).
> 5. Adding a commit involves considerably fewer steps since there isn't
>   any pull/push and your local changes are always implicitly rebased
>   on|svn update|.
>    1. Commits are authenticated. By default in git I can tell it I'm
>       committing as anyone.
> 6. Subversion is easy to use
> 7. Merges are forced immediately (by someone defined as "killer feature
>   of SVN")
> 8. SVN doesn't break your brain (<--- love that one)
> 9. SVN handles binaries better
> 
> 
> In several places I read that the concept of "cherry picking" is seenas bad 
> (even cited in monotone's wikipedia page) with certain people coming up with: 
> "/Conclusion: Subversion unifies a team/", the fact that you can do many 
> things in SVN in only one way and in a simple and easy way, makes it easy to 
> learn.
> 
> I think that 1) can be of interest too, it is actually one thing I disliked 
> in CVS and one of the few arguments that slowly made me migrate to SVN.
> 2) is interesting too and I have used that feature extensively.
> The arguments about 9) are varied, but most people write that, we have 
> several.
> 5.1 is also nice: once I make it to a commit, it is commited! I'm saved!
> 
> Of course, you will find a lot of "pro GIT" articles: clear, if it is a trend 
> it is always so, I just wanted to point out that SVN works for us and works 
> quite well
> 
> I may add that svn being around since a longer time is available on more 
> machines and as you know I do like to check out stuff on stranger machines. 
> Other people might care less, but testing on strange stuff is good and fun.

Well, you can always check out on one machine with git support and copy the 
tree to the other where git is not supported.

> 
> Riccardo
> 
> Gregory Casamento wrote:
>> Hey guys,
>> 
>> I wanted to run this past the community to see what the general feeling is.  
>> I am considering a move back to savannah utilizing git instead of subversion.
>> 
>> The implementation of git on savannah, I believe, allows checkout and 
>> check-in VIA subversion.  I would at least like to try to maintain a mirror 
>> there (like the one on github) so that everything can be accessed in one 
>> place and those who want to use git can do so.
>> 
>> The reasons I have for thinking about using git are:
>> 
>> 1)  the branching and cherrypicking capabilities.  I think it's well known 
>> that git's capabilities in this area far outstrip those of SVN hands-down.  
>> I don't think there's any debate on this issue.
>> 
>> 2) community. Rightly or wrongly a large community of developers prefer git 
>> over any other SCMS.   While I understand that certain people in our 
>> community don't like git for religious reasons, I also think it's time to 
>> reconsider religious arguments for technical decisions.
>> 
>> 3) Actively developed.  GIT is under active development. There have been few 
>> releases of SVN over the last few years. One might attribute this to 
>> stability, but there haven't been that many advancements in SVN in a while.
>> 
>> 4) Tools.  There are a wider range of tools on Linux, Windows and Mac to 
>> deal with git repositories these days. Additionally there are tools which 
>> can be used to make code reviews much easier.
>> 
>> I would like to reach some sort of consensus on this rather than a flame 
>> war.  I would ask that only active committers comment on this email thread 
>> so that we can be clear about the reasons for or against this move.   I have 
>> stated the reasons I have above.
>> 
>> Please let me know what you think.
>> 
>> GC
>> 
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep