3 ms·
I have some questions about Why.html: https://www.bitkeeper.org/why.html https://www.bitkeeper.org/why.html > Spending a lot of time dealing with manual and ba
by civilian 10y ago
I have some questions about Why.html: https://www.bitkeeper.org/why.html https://www.bitkeeper.org/why.html
> Spending a lot of time dealing with manual and bad auto-merges? BitKeeper merges better than most other tools, and you will quickly develop confidence in the quality of the merges, meaning no more reviewing auto-merged code.
Do you have examples of merge-scenarios that are a Conflict for git but resolve for BK?
> BitKeeper’s raw speed for large projects is simply much faster than competing solutions for most common commercial configurations and operations… especially ones that include remote teams, large binary assets, and NFS file systems.
Is there a rule of thumb for what size of repos benefits from BK? (And I suppose size could either be the size of a current commit or the total size of the repo.)
Are there any companies like github or bitbucket that support BitKeeper repos?
- luckydude 10y agoWayne pointed to some stuff over on the reddit thread. As for size it's csets * files, as that gets big, Git slows down faster than linear, we're pretty linear.
- thspimpolds 10y agoI think you guys undersell BAM. That was such a clutch feature where i used BK. It's sad seeing git large file handling just show up, I garuntee it has a long way to go to get parity with BAM.