[haiku-development] Re: Proposal: Moving away from Subversion
- From: Travis Geiselbrecht <geist@xxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 28 Jun 2010 09:02:20 -0700
On Mon, Jun 28, 2010 at 6:26 AM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> Andreas Färber <andreas.faerber@xxxxxx> wrote:
>> Am 23.06.2010 um 10:14 schrieb Axel Dörfler:
>> > For me, git is out of the question, not only because of the
>> > revision
>> > numbers, but also because of its incredibly bad user interface,
>> Hm? Anything in particular?
>> I find the porcelain's implicit use of less very handy, for instance.
>
> I am mostly referring to the 130 hard links it clobbers your "bin"
> directory with. This is just unacceptable non-sense, and hints to an
> incredible developer stupidity :-)
> The other part of the bad user interface is not only that the terms
> differ from what most tools are using (and therefore, most people are
> used to). If you've read the git vs. hg comparison article recently
> qouted in this thread, you pretty much get the idea of my critic.
The hard links are gone in newer versions, iirc. It was there to
support the older way of calling it via the git-<command> process
wrappers. Now the only real way to use it is via git <command>. If
they still generate them in their install process they can probably be
left out.
>> > and
>> > things like the need to rebuilt its internal database from time to
>> > time.
>> Are you referring to the optional git-gc cleanup? You can turn it off
>> if you don't care about disk space:
>> http://www.kernel.org/pub/software/scm/git/docs/git-gc.html
>
> That's not really an option, and is not something the user should care
> about at all. It's just bad design, similar to chkdsk kicking in every
> few boots on an ext3/4 installation; it's a completely unnecessary
> perfomance killer.
The GC is just there to pack new data in efficiently. Its absolutely
no where near the problem you're making it out to be. As new objects
are added to the backing store, they're added as naked objects (in a
separate file). When a certain number of them builds up, it
automatically kicks in a gc that just packs them into a .pack file. A
pack file is basically just a pile of compressed objects, stored as
deltas from each other. It's really no big deal. You can fire off a gc
when you feel like it or just completely forget about it.
I've tried to measure the difference between a packed and mostly
unpacked backing store and haven't been able to see any real
performance difference.
Travis
Other related posts:
