|
|
|
|
|
by garibaldi
5514 days ago
|
|
I work for a company which uses hg exclusively. I think it's a great version control system, but it suffers from an annoying implementation problem which gets in the way of our workflow. When an hg pull is performed the pulling repository must let the other repo know about the state of each of it's branches. This includes closed branches. In addition, hg uses HTTP as it's network protocol. I think it transmits it's branch info as part of the headers in a GET request. The result is that once you have a certain number of branches in your repo the pulls fail because there isn't enough room in the headers to transmit the state of the repo. We are heavy users of branches for features/bugfixes as this helps us to improve quality control. This hg shortfall means we have to rethink our souce control procedures, we only learned about this problem when we encountered it - several thousand changesets into using hg. Apparently a fix is several months away from being in an hg release. hg is great, but the above problem + the mutable changesets offered by git now has me leaning more towards the git camp. |
|
Just curious, how many branches do you have in the repository?