I believe it's the case that there's generally no restriction on the length of bookmark names, however trying to push bookmarks of length >255 results in an exception being raised. $ export LONG_BOOKMARK=a$(seq -s '' 300) $ hg init repo1 $ hg clone repo1 repo2 $ cd repo2 $ touch a; hg commit -Am a adding a $ hg book ${LONG_BOOKMARK} $ hg push -B ${LONG_BOOKMARK} pushing to /Users/michaeloconnor/repo1 searching for changes ** unknown exception encountered, please report by visiting ** https://mercurial-scm.org/wiki/BugTracker ** Python 2.7.10 (default, Oct 23 2015, 19:19:21) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] ** Mercurial Distributed SCM (version 3.7.3) ** Extensions loaded: Traceback (most recent call last): ... File "/usr/local/Cellar/mercurial/3.7.3/lib/python2.7/site-packages/mercurial/bundle2.py", line 936, in getchunks paramsizes = _pack(_makefpartparamsizes(len(parsizes) / 2), *parsizes) The issue can at least currently be worked around by not using bundle2 to push bookmarks. $ cat > /tmp/long_bookmarks.py <<EOF def uisetup(ui): import mercurial.exchange as exchange exchange.b2partsgenorder.remove('bookmarks') del exchange.b2partsgenmapping['bookmarks'] EOF $ hg --config extensions.long_bookmarks=/tmp/long_bookmarks.py push -B ${LONG_BOOKMARK} pushing to /Users/michaeloconnor/repo1 searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files exporting bookmark a1234...
Oops, I don't think there was a official limitation in pushkey (but some actual limitation of http protocol), Should we add a sensible size limit to names from now?. (I'll look at a work around for this this week).
Thanks! It would be convenient for us if it were possible to keep the length of bookmarks unrestricted: we have a code review system which puts some structure into bookmark names and this can cause our bookmark names to occasionally become quite long. For example, if someone is working on a change called A which depends on a change called B which depends on a change called C, our code review system will set things up so this work goes in a bookmark called C/B/A.
Nothing decided yet, but I think it would make sense to limit name length so it might happen. If it happen can you think of an alternative way to encode this dependency information?
I'm not sure it really fits our BC guidelines to try and limit bookmark names now. Why can't we fix bundle2?
Bug marked urgent for 10 days, bumping
Bookmarks name already have a length limit because of pushkey implementation, they are just higher. Michael O'Connor workflow was going to hit it one way of another anyway. I would advise for encoding this information another way. I think it make sense to enforce clear and sensible limit on our naming scheme, we already restricted some after the fact for special characted in bookmarks and branch I think enforcing a 255 bytes limit make sense here.
Over ssh I'm pretty confident bookmarks have no length limits. Over http, it's certainly in the multiple kilobytes range. I think trying to retroactively declare bookmarks over 255 bytes in length a bug is a clear violation of our BC policy.
Bug marked urgent for 11 days, bumping
Bug marked urgent for 155 days, bumping
We have a patch ready that move bookmarks to a binary bundle2 part, moving the size limit from 255 to 64K. @Michael would that be sufficient for your case?
Not Michael, but same company. 64k is definitely more than enough. I would expect 64k-long names to break other tools built on top of hg, or run into filesystem limits anyway. It would be great to see a fix for this land quickly in hg, as downgrading to bundle1 causes pain in the form of not getting the improvements made by bundle2, like better performance and behavior (atomicity, don't push revisions when the bookmarks raced, maybe others).
Fixed by https://mercurial-scm.org/repo/hg/rev/3340d46a5c3f Boris Feld <boris.feld@octobus.net> bookmark: add methods to binary encode and decode bookmark values Coming new bundle2 parts related to bookmark will use a binary encoding. It encodes a series of '(bookmark, node)' pairs. Bookmark name has a high enough size limit to not be affected by issue5165. (64K length, we are well covered) (please test the fix)
Fixed by https://mercurial-scm.org/repo/hg/rev/dbf868623daf Boris Feld <boris.feld@octobus.net> bookmark: add a 'check:bookmarks' bundle2 part This part checks that bookmarks are still at the node they are expected to be. This allows a pushing client to detect push race where the repository was updated between the time it discovered the server state and the time it managed to finish its push. Such checking already exists when pushing bookmark through pushkey. This new part can be inserted at the beginning of the bundle, triggering abort earlier. In addition, we would like to move away from pushey to push bookmark. A step useful to solve issue5165. (please test the fix)
Fixed by https://mercurial-scm.org/repo/hg/rev/a1e70c1dbec0 Boris Feld <boris.feld@octobus.net> bookmark: use the 'bookmarks' bundle2 part to push bookmark update (issue5165) We use the new binary parts we introduced earlier to exchange bookmark. The payload is a bit more compact since we use binary and the length of bookmarks is no longer constrained to 255. .. fix:: Issue 5165 Bookmark, whose name is longer than 255, can again be exchanged again between 4.4+ client and servers. (please test the fix)
Bug was set to TESTING for 7 days, resolving
Fixed by https://mercurial-scm.org/repo/hg/rev/09b58af83d44 Augie Fackler <augie@google.com> bookmarks: test for exchanging long bookmark names (issue5165) As far as I can tell a test for a long bookmark name never actually got added when this was fixed. Let's document that a 300 byte bookmark is something we're supporting (this patch started out life over a year ago as a way for me to validate the problem, and I recently found it.) I think the nonzero exits from the push operations are only because no new changesets get exchanged. Please correct me if I'm wrong on that. :) Differential Revision: https://phab.mercurial-scm.org/D2727 (please test the fix)