Hi Christian,
This costs tons of additional disk space and CPU time because you have
to rebuild everything from the ground up
This is not true for any filesystem that supports hardlinks. Do a clone
only, then an update. Only when you don't clone it completely, you have
to rebuild everything (and indeed, that is rather slow, and furthermore
you won't have history for anything that happened after the revision you
based your clone on, so this is not what you usually want).
perhaps you did not fully understand what I mean. When you have cloned a
remote repo to a local one, got a working tree and have already build it
you've got tons of object files, libraries, executables etc. that are not
under version control.
Now, when you want a branch, the Mercurial way is to clone again from your
local repo. This will not copy the aforementioned object files, libraries
etc.
So you have to do the whole build / compilation again - unless you
selectively copy that files into your freshly cloned repo - and even then
you've doubled the disk space required for it.
In Git I can simply switch the branch and then some sources & makefiles
files are changed, removed or added as needed. Those files will get
assigned the current time so that another 'make' run will recognize they
have changed. Hence only the required files are recompiled, relinked etc.
provided your dependencies are properly configured in your makefiles etc.
So regarding OOo if I changed one C++ source by going back in history to
an already existing branch that would lead to rebuild of a shared object,
which is needed for just one binary I could be finished within minutes
whereas in Mercurial I would have to create a fresh clone and wait some
hours until everything has been rebuilt.
But again: Cloning is fast when using hardlinks and cloning the full
repo. Also it then doesn't need much diskspace either. If you trust your
editors/other tools, you can even use hardlinks for the files under
version control, not only fo the repository's data.
If you use 'vim' you can configure it to break hardlinks on save, yes. But
this won't help as you don't have your object files etc.
Even the repo history must be duplicated in Mercurial if the clone is
not to be placed on the same physical filesystem because the hardlinks
don't work in this case (which requires n times the storage).
This is true, but is this really relevant?
Yes, of course it is.
I've just mentioned it in the other email, not everyone is just working on
his own PC with a cheap 500 GB disk inside. Server disk space is really
very expensive - it is mostly mirrored inside a RAID and remotely backed
up, several years in use, you can't put in cheap replacements as you need
exactly that old disk model; so that your disks might be older with less
capacity so that you have to split up work onto several filesystems etc.
This is no joke, believe me, that's real life. When I'm working on Solaris
sparc systems, I have to do it server based, no way to use my Windows
based Intel Laptop for it (and even that one is bought with a minimum of
disk space by the company in order to save as much money as possible).
Well, the clones are references to the base as well, so you can pull
from that base withoutt problem, so in fact having one base-repo and
several slave-clones is the default in mercurial.
Might be, but in Git you can have it all in one repo at your fingertips.
You don't need to go to a seperate repo directory if you want to compare a
file to an earlier release just because it is in that other branch.
I hope you don't get the feeling that I'm strictly against Mercurial - I'm
definitely not. I have even contributed a little bit to it's book, and I
strongly prefer the User interface over the Git one. I keep on monitoring
Mercurial's, Bazaar's and Git's development.
However regarding branches, I'm a supporter of the Git model.
Best regards
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
