Graeme Geldenhuys schrieb: > Florian Klaempfl wrote: >>> Most importantly, if you accidentally commit file with wrong line >>> endings, you can fix that >>> rather easily in git, nut with svn, you are screwed. >> Well, usually one notices only if it is pushed/pulled. > > Then that developer will definitely not be in my team (or yours I hope). > Because he/she doesn't review code before making it public.
One creates a new file my.pas with wrong line feeds, adds/commits/reviews/pushes it. How shall he recognize this? The next person working with the file will find out only. This is the simplest case, it gets more complicated if one works on samba shares and tortoisesvn with unix editided files like I do often :) And yes, sometimes I forget the review, simply because I do a lot of other things while working (house keeping, parenting etc.) on fpc. Even more, since the most important point in fpc is regression testing before committing instead some useless "I've another stupid look at my code". > > >>> That is meaningless concept in git, see e.g. >>> http://stackoverflow.com/questions/612580/how-does-git-solve-the-merging-problem >> See my mail to Graeme, then git simply does not fit into FPC's workflow. > > You play to the strengths of each tool. You guys use SubVersion different > to the recommended way of the official SubVersion documentation > (http://svnbook.red-bean.com/), by treading "tags" like branches and > placing commits in them (just one such example). I have not come across > other projects that do that, so FPC is unique in there workflow. Possible, yes. Very few projects do also binary release building for such a number of different architectures as we do. > > Just like Git saw the problems of previous SCM software it tried to improve > those problem areas with new features and design. So it would make sense > that if you switched to Git, you try those new features as recommended and > then review your workflow accordingly. So make a recommendation for the fixes branch workflow instead of talking about the fix one, break one design of git. How shall we adapt the workflow so that nobody wastes it time with trying to merge stuff somebody else examined already? > Every Monday I update the "fixes" branches in the Git mirror repositories > for FPC and Lazarus. I ask svn2.freepascal.org for a commit log between > HEAD and the last revision (previous Monday)... I then go make a cup of > coffee and often by the time I get back, $ time svn log -r HEAD:14620 http://svn2.freepascal.org/svn/fpc/branches/fixes_2_4 > /dev/null real 0m0.792s user 0m0.010s sys 0m0.020s You must have a really fast coffee machine ;) -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
