Replies are below inline... On Mon, May 25, 2015 at 9:26 AM Riccardo Mottola <riccardo.mott...@libero.it> wrote:
> 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 > Git 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. > As can git. In git they're called submodules. > 3. SVN supports exclusive access control|svn lock|which is useful for > hard-to-merge files (cited several times for difficult merges) > Exclusive access is a bad idea, period. > 4. SVN supports binary files and large files more easily (and doesn't > require copying old versions everywhere). > Where are you getting this misinformation. Git supports binary files just fine. I have had no issues with large images and various other data in projects I've worked on in the past. Furthermore, we have no terribly large datasets or images in our repo. > 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. > 1 step more for git for the added benefit of being able to have any repo act as a remote. Not much of a price to pay. Git commits can be authenticated as well. In both systems this is an option. In git you must have an entry in your .ssh which corresponds to the identity you are using to commit with. On github see the page about committing with multiple ids. > 6. Subversion is easy to use > An unqualified statement. Git is very easy to use. Only those who were exposed to it several years ago and haven't used it since would say it's hard. The current maintainer has removed much of the confusing parts of git that plagued it in the past. > 7. Merges are forced immediately (by someone defined as "killer feature > of SVN") > They are not forced. You must pull in > 8. SVN doesn't break your brain (<--- love that one) > Huh!? Only if you don't understand the difference between the paradigms of the two systems. > 9. SVN handles binaries better > > Mentioned and addressed in the comment above. > 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. > > LOL... I don't get this one. I don't reach that conclusion at all. 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! > This can be a bad one. Once you've committed maybe you need to revert. In SVN it's a lot harder than in git. In git all I need to do is revert a commit. In svn I must check out the previous version, copy and then check in... or I must make a patch. > 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'm not caring about trends. Only pure experience. Most if not all of the projects I have done recently have used git and it's a pleasant experience. > 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. > > git is available on every platform we are interested in. > 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 > > > >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
