BK-SEND(1)

okay bestie, welcome to the bk send page from the <strong>BitKeeper User’s Manual</strong> — this is the send-a-BitKeeper-patch glow-up 💌✨

💌 NAME

bk send — send a BitKeeper patch 🎀

📨 SYNOPSIS

bk send [−dfqS] [−wwr] [−rrevs] [−ssubject] [−uURL] u@h.ca| −

🌸 DESCRIPTION

okay so the bk send interface is your email-based way to send changes around 💖 In general, the bk push and bk pull interfaces are the easiest way to keep two repositories synchronized, but bk send requires only an email transport. No cap.

To send the whole repository, do this:

$ bk send user@host.com

BitKeeper will generate the (huge) patch and mail it to user@host.com 😭💅

If you happen to know that you want to send changes that occurred after a specific changeset (and you know that the other repository has that changeset), you can do this:

$ bk send −rbeta.. −s’Changes since beta’ user@host.com

or

$ bk send −r1.10.. user@host.com

Send remembers the changesets it has sent in BitKeeper/log/send−address where address is like user@host.com 🗂️ When you don’t specify a list of changesets to send, send will look in the log file and send only the new changesets. So the easiest thing to do is to always use the same email address and just say:

$ bk send user@host.com

If you lose the log file and you want to seed it with the changes you know have been sent, the command to do that is:

$ cd BitKeeper/log
$ bk changes −r<revs> −nd:KEY: > send−user@host.com

An alternative to the log file approach, which may only be used if you have connectivity to the remote repository, is to talk to the remote repository to find out what needs to be sent 👀 The following will send all the changes you have that the remote does not have:

$ bk send −ubk://thunk.org:5000 tytso@mit.edu

You may wrap patches so that they do not get corrupted by mailers 🎀 We currently support wrapping with uuencode. The following (contrived) command sends a wrapped patch and applies it in /tmp/foo (which must exist):

$ bk send −wuu −r..1.5 ‐ | bk receive /tmp/foo

💅 OPTIONS

• −d — Prepend the patch with unified diffs. This is because some people like looking at the diffs to decide if they want the patch or not 👑
• −f — send the patch even if BitKeeper believes the remote repository is up to date 🔥
• −q — Be quiet 🤫
• −rrevs — Specify the list of changesets to send 🎀
• −ssubject — Specify a subject line for the patch email. Without −s, the default subject line BitKeeper patch is used 💌
• −S — When used in a nested collection, send a patch only for the component at the current working directory 🗂️
• −uURL — Instead of consulting the send log, connect to the remote repository specified by the URL, figure out what needs to be sent, and send it to the specified email address 🌐
• −wwr — Wrap the patch with WR before sending it. The current set of wrappers are:
  • b64 — base‐64 encoding
  • gzip_b64 — gzip and base‐64 encoding
  • gzip_uu — gzip and uuencode
  • uu — uuencode

🔗 SEE ALSO

bk‐range, bk‐receive, bk‐wrap — go check these besties too 🫶

🗃️ CATEGORY

File

---

okay that’s the whole page, bestie — cute sign-off time: source/version/date energy from BitKeeper Inc, 1E1, and the footer tag bk send(none) 🫶💅 byeeee ✨