Hi,

As promised, here is the final details of comparing SubVersion and Git using the *full* Lazarus history.

Lazarus repository statistics:
* repository age is 8 years and 3 months
* 23 unique users have committed to the repository in that time
* 17246 revisions have been recorded.

SubVersion sizes:
-----------------------
* HEAD normal checkout = 314MB (that means 1 revision only and no history)
* HEAD exported (no .svn folders) = 76MB (latest revision of source code only)

So far that means SubVersion adds 238MB of noise simply to manage ONE revision!!! I guess there is a lot of crap in those .svn folders.

Git sizes:
------------
* HEAD checkout using Git = 108MB (that's 1 revision with no history
- which is what svn does normally)

So Git is already 206MB smaller than SubVersion using the HEAD revision only. That's quite a saving of space, but that's not the impressive bit yet.

* Complete checkout with *full* history of every revision = 133MB!!!

That means Git add only 25MB to manage 17246 revisions of history! Plus the full history with Git is smaller than a single checkout with SVN!!

So I then compressed the full history checkout with Git using 7zip. That created an archive of 66MB. So to summarize: You can download the full history of Lazarus repository for only 66MB and it is smaller than a single (latest revision) checkout via SVN. If Lazarus every decides to move to Git, I would recommend such an archive gets created on a monthly basis. So users can download, unpack and then do a update.

SVN doesn't have an option to checkout the full history to the client side, so I can't compare that size, but I can image it must be in the Gigabyte range considering that a single revision takes up 314MB and there are 17246 revisions!

So there is no doubt that Git is extremely optimized for size and it's very impressive how much information it can store in such a little space. Plus it will save considerable download time.

I'll be keeping the Git version of the Lazarus repository. So if total disaster strikes you guys can simply get a copy from me. ;-)

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

SVN doesn't have an option to checkout the full history to the client side,

It does and is called svnsync. It creates a mirror.

Vincent

I was referring to the client tools like the svn client. As far as I understand, svnsync mirrors the repository, so you need to run a SubVersion server/repository locally. It still doesn't allow the svn client to have all the history in a single directory where the source code lives. Or am I not understanding the svnsync tool correctly?

Regards,
- Graeme -

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

All this is very correct, but largely irrelevant.

I considered Git for use in my company, (subversion is quite bad for handling lots of banches) and frankly: I decided against it because people here couldn't understand it.

They have a hard time understanding Subversion (or CVS or any of it), and git is even 2 notches harder to understand. That and the fact that there is no decent GUI clinched the matter.

Sometimes one must weigh the technical features against practical usage.

I can have the best technical system of the world, but if I'm the only one understanding it - in my company - it is simply ruled out.

Michael.

I think you understand it correctly. What is a the git equivalent of a svn server containing the history? If you want to compare only the svn client, you must remove that part from git, that is the equivalent of svn server containing the history. If you don't want to do that, you must allow to install a local svn server, maybe not as comfortable as git, though.

Vincent

Hi, As promised, here is the final details of comparing SubVersion and Git using the *full* Lazarus history.

A git repository of full fpc takes 1,2 GB (checkout of trunk+history).

That I understand all to well. We had the same issue when we moved from Team Coherence to SubVersion. SubVersion could really do with a GUI like TC has. Anyway the "hard to understand" issue was easily resolved by writing a short 1 page summary of the most common commands they would need for every day work. Then as they get familiar with the tool after a few months, we started introducing them to new commands (if needed). We also setup a "sandbox" repository for them to experiment in - they really liked that. :)

That and the fact that there is no decent GUI clinched the matter.

I know of two and a few in the pipe-lines. But then, I'm a CLI guy. Anyway, I also found a very nice site showing the SubVersion commands on one side and the Git commands on the other. Most Git commands where shorter and quite easy to understand. But yes, as with any other tools, there will be a period containing a learning curve.

Sometimes one must weigh the technical features against practical usage.

True. I must say, I'm very impressed with "svnmerge.py" tool. I have been playing with it for the last 30 minutes. It makes SubVersion branching much easier! I've always avoided branching in SubVersion even though branching is very handy, simply because it is overly complex. Git makes this as simply as pie (out of the box).

Regards,
- Graeme -

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

SubVersion is already very inefficient when it comes to disk space. So now you are suggesting I run a SubVersion server locally (+-250MB of data) and the setup of svnd (subversion daemon) and have a local checked out repository (another +-310MB) just so I can see the history of files quicker.

Git can do all that in a single directory tree, no daemon and only use 133MB.

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

Git can do all that in a single directory tree, no daemon and only use 133MB.

For you git is probably better, I suggest you start using it. IIRC, you can use git as a front to an existing svn server.

Vincent

Florian Klaempfl wrote

A git repository of full fpc takes 1,2 GB (checkout of trunk+history).

Yes, but you probably forgot the last few steps. Lazarus was 1.5GB after the initial checkout from SubVersion to Git.

Missing steps:
-------------------
* After checking out data from SubVersion to Git, the Git repository has tons of SubVersion info stored. You need to remove that uncessasary stuff if you are switching to Git.
* Repack the repository, so it can optimized the delta's between revisions.

Both these steps can be done with one command. Assume 'temp_repos' contains the repository you checked out from SubVersion using Git.

cd ..
git clone temp_repos clean_repos
rm -rf temp_repos
cd clean_repos

The "clone" command will recreate the repository into a new directory called 'clean_repos'. It will remove all the SubVersion information making it a Git-only repository and then rebuild the deltas.

With Lazarus, my 'temp_repos' was 1.5GB and the 'clean_repos' was 133MB after the clone/repack command.

For more details on converting a SubVersion repository to Git: http://djwonk.com/blog/2008/05/09/cleanly-import-svn-repository-into-git/

Once you use a Git-only repository, you can repack your local repository every few months, to optimize the revision deltas and save space. There is a repack specific command for this.

Regards,
- Graeme -

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

Vincent Snijders wrote

For you git is probably better, I suggest you start using it. IIRC, you can use git as a front to an existing svn server.

That's what I am doing now. :-) I've never used Git before yesterday. So I'll use my Git wrapped Lazarus repository and see how it goes. I have my crypt notes on a post-it note showing me the equivalent SVN commands for Git. So far the commands are straight forward.

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

That I understand all to well. We had the same issue when we moved from Team Coherence to SubVersion. SubVersion could really do with a GUI like TC has.

I don't know TC and it's GUI, but for cvs and svn there is always TkCVS. Despite it's name it can handle svn nowadays and since it's written in tcl/tk it run anywhere (yes, I did use it on windows with cvs).

Hopefully I got the URL correct (source is on sf.net):

http://www.twobarleycorns.net/tkcvs.html

HTH,
Marc

Marc Santhoff wrote

I don't know TC and it's GUI, but for cvs and svn there is always TkCVS.

Thanks, I'll take a look - though I love my CLI interface and it's consistent across platforms. Maybe the next new developer in our company can start of with a GUI if they wish.

As for Team Coherence. The website is here:
http://www.teamcoherence.com/

And here's a screenshot:
http://www.teamcoherence.com/images/vmmain.jpg

Regards,
- Graeme -

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

BTW, Lazarus has it's own SVN GUI interface plugin in case you didn't know. It's named lazsvnpkg and can be found under ./components. Mind you it's still under developement (working on the repository browser right now), but basic stuff is in.

Darius

Am Donnerstag, den 06.11.2008, 15:33 +0100 schrieb :

Thanks for pointing this out, I didn't know yet and will test it as soon as possible.

I'd love to have one tool less, although the graphical tree (depending on special comments in cvs's "modules" file :( ), tkdiff and lots of warning dialogs are really helpful.

Regards,
Marc

Marc Santhoff wrote

I'd love to have one tool less, although the graphical tree (depending on special comments in cvs's "modules" file :( ), tkdiff and lots of warning dialogs are really helpful.

Either create a patch or file a feature request :)

There's nothing that prevents us from improving the tool, is there?

Darius

I'll be keeping the Git version of the Lazarus repository. So if total disaster strikes you guys can simply get a copy from me. ;-)

Well, if there is real interest, we can of course create an offical git mirror.

From what I've heard... Git is better in most circumstances, excepting

complexity, (G)UI, and Windows compatibility.

So, Graeme can keep up the Git repository, until the time that Git sorts out those issues, then we already have a repository converted, and it'll take little to no time to convert everyone (if all votes Aye!).

Also I guess if SourceForge starts offering Git, that'll show that it's become a standard in the industry. (Do they already?)