[Lazarus] DSCM, was Re: Groundwork for Undo in Form Designer

Florian Klaempfl florian at freepascal.org
Mon Jan 18 11:21:47 CET 2010


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 ;)





More information about the Lazarus mailing list