[Lazarus] Groundwork for Undo in Form Designer

Alexander Klenin klenin at gmail.com
Mon Jan 18 10:04:21 CET 2010

I tried to stay away from the flame, but just could not resist, sorry ;-)

On Mon, Jan 18, 2010 at 17:47, Florian Klaempfl <florian at freepascal.org> wrote:
> Well, I don't wonder, you always tell us how great git is but at every
> thing I look, it plainly sucks:

> - git svn
Well, I agree it is not the best part, I admit, but it sucks only slightly more
then plain svn, since that is where most of "git svn"'s limitations come from.

> - line feed handling (how can I do it failsafe?)
In short, set core.safecrlf=true in your gitconfig
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.

> - merging (how do I merge blocking?)
That is meaningless concept in git, see e.g.

> - handling of empty directories
Yes, that is a wart, but how many empty directories are there in
Lazarus repository?

> - tortoisegit (ever used tortoisesvn?)
Not only used, but was an active contributor:
However, I abandoned it in favor of git, and have no regrets ;-)
I would recommend using built-in git tools (git gui and gitk) instead
or tortoisegit.

> Of course, it's all my fault that I don't see the use of the unix script
> hackery called git. So you can continue to ignore the concerns and we
> will continue to use svn :)
Well, script hackery is a good thing to many ;-)

I used svn for many projects and still continue to use it for the projects
that did not move on (that's three projects now, counting Lazarus).
And I liked (and still do), but I found out that there is an even
better alternative.
Now, let me list some problems I have with svn:

1) It is slow to the point of being unusable.
Using TortoiseSVN, "Show log" on the root of Lazarus folder takes
anywhere from 15 seconds to 2 minutes. (And yes, log cache is on).
Diffing a file to see a change introduced by some commit takes
from 30 seconds to 5 minutes (especially for gigantic files like main.pp).
Both operations are instantaneous (<1 sec) in git.
2) Update is also slow, but less so and git is merely twice as fast,
to 50 times.
3) You can not fix a mistake in history. Once I discovered the power
of "git commit --amend"
and "git rebase --interactive", I would recommend git based on these
two features alone.
4) You can not (easily) commit part of the file.
5) You can not (easily) manage more that one change concurrently, especially
  if they touch common files.
6) You can not experiment with a feature requiring more than one commit,
  that is, any non-trivial feature, without a commit access.

Alexander S. Klenin

More information about the Lazarus mailing list