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

[Graeme Geldenhuys]

Florian Klaempfl wrote:
> 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 :)

I use my flashdrive like that. I simply told git to always store files as
LF in the repository. Any editor (worth using) can handle files with
different end-of-line characters compared to the default OS.

If I really wanted to change my files to CRLF for usage under Windows, I
can simply run 'git config core.autocrlf true' and then 'git reset --hard'.
The first command doesn't change the eol characters in the repository (git
repository storage always uses LF), but it will convert eol characters to
CRLF when you checkout a branch/tag/revision etc... The second command
simply forces git to re-get all files from the repository data storage,
which causes all files to have their eol chars converted to CRLF.

The reverse is possible too, but like I said, with my existing repositories
on my flashdrive, I just keep all source code with eol characters as LF,
even under Windows. Even if I used Lazarus under Windows and check in a new
unit, the unit might have CRLF, but the file stored in the git repository
is always LF.


> 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?

Simply pull that feature branch from the developer that already did the
merge. Also remember that Git is much better at auto resolving merges than
SVN, so conflicts are less prone. Don't ask me how it works, I only know
that it does. :)


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

It's a continuous boiling urn actually. :)

-------------------------------
$ time svn log -r HEAD:14620 \
    http://svn2.freepascal.org/svn/fpc/branches/fixes_2_4 > /dev/null

real	0m22.514s
user	0m0.020s
sys	0m0.012s
-------------------------------


Today seems to be a good day, only took 22 seconds seconds.


Now here is another example, using the <lazarus>/ide/main.pp file.

First with Git:
-------------------------------------
$ time git blame -- main.pp > /dev/null

real	0m11.045s
user	0m10.945s
sys	0m0.100s
-------------------------------------


And now with SVN (SubVersion command line client):
-------------------------------------
 $ time svn blame http://svn.freepascal.org/svn/lazarus/trunk/ide/main.pp >
/dev/null
real	4m38.046s
user	0m16.489s
sys	0m7.852s
-------------------------------------

More than enough time to make a cup of coffee. ;-)


Now imagine searching for a regression bug in Lazarus using SVN.
Continuously checking out various revisions (high-low, test, high-low,
test..) First of all, just a few such bugs and I would have depleted my
home internet 500MB data limit per month. Also, the time it would take to
checkout out a full copy of the repository each time will be huge (a few
minutes for each checkout)! With Git such checkouts do not require network
access and a checkout (any revision) will take <5 seconds.

There are many other such use-cases where DSCM's like Git and Mercurial
will trump SubVersion every time. And like you said, you spend a lot of
time doing regression tests. (did I mention you can automate regression bug
tracking with Git using simple test projects like the ones used in FPC
tests directory)


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/