Roman Zippel wrote:
Preserving the complete merge history does indeed make repeated merges
simpler, but it builds up complex meta data, which has to be managed
forever. I doubt that this is really an advantage in the long term. I
expect that we were better off serializing changesets in the main
Roman Zippel wrote:
Please show me how you would do a binary search with arch.
I don't really like the arch model, it's far too restrictive and it's
jumping through hoops to get to an acceptable speed.
What I expect from a SCM is that it maintains both a version index of the
directory structure
Roman Zippel wrote:
It seems you exported the complete parent information and this is exactly
the nitty-gritty I was whining about and which is not available via
bkcvs or bkweb and it's the most crucial information to make the bk data
useful outside of bk. Larry was previously very clear about
Patrick McFarland wrote:
On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote:
Something that unintentionally started a flamewar.
Well, we just went through another round of 'BK sucks' and 'BK sucks, we need
to switch to something else'.
Sans the flamewar, are there any options? CVS
Paul Mackerras wrote:
Rik van Riel writes:
Thing is, the rest of the kernel uses virt_to_phys for
two different things. Only one of them has to do with
the real physical address, the other is about getting
the page frame number.
So fix the places that are using virt_to_phys to get the
Alan Cox wrote:
On Mer, 2005-03-09 at 22:22, CaT wrote:
Argh! Ok. I guess I shouldn't've just bought the card based on this
driver then so that I could better debug my problems with my promise
cards. 8(
Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1
Arjan van de Ven wrote:
* hardware firewall -- sounds silly. Pretty sure Linux doesn't support
it in any case.
probably just one of those things implemented in the binary drivers in
software, just like the hardware IDE raid is most of the time (3ware
being the positive exception there)
Patrick McFarland wrote:
On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote:
Something that unintentionally started a flamewar.
Well, we just went through another round of 'BK sucks' and 'BK sucks, we need
to switch to something else'.
Sans the flamewar, are there any options? CVS
Roman Zippel wrote:
Preserving the complete merge history does indeed make repeated merges
simpler, but it builds up complex meta data, which has to be managed
forever. I doubt that this is really an advantage in the long term. I
expect that we were better off serializing changesets in the main
Roman Zippel wrote:
Please show me how you would do a binary search with arch.
I don't really like the arch model, it's far too restrictive and it's
jumping through hoops to get to an acceptable speed.
What I expect from a SCM is that it maintains both a version index of the
directory structure
Roman Zippel wrote:
It seems you exported the complete parent information and this is exactly
the "nitty-gritty" I was "whining" about and which is not available via
bkcvs or bkweb and it's the most crucial information to make the bk data
useful outside of bk. Larry was previously very clear
Alan Cox wrote:
On Mer, 2005-03-09 at 22:22, CaT wrote:
Argh! Ok. I guess I shouldn't've just bought the card based on this
driver then so that I could better debug my problems with my promise
cards. 8(
Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1
Paul Mackerras wrote:
Rik van Riel writes:
Thing is, the rest of the kernel uses virt_to_phys for
two different things. Only one of them has to do with
the real physical address, the other is about getting
the page frame number.
So fix the places that are using virt_to_phys to get the
Arjan van de Ven wrote:
* "hardware firewall" -- sounds silly. Pretty sure Linux doesn't support
it in any case.
probably just one of those things implemented in the binary drivers in
software, just like the "hardware" IDE raid is most of the time (3ware
being the positive exception there)
14 matches
Mail list logo
