-
Notifications
You must be signed in to change notification settings - Fork 1
/
RELEASE-NOTES
424 lines (330 loc) · 16.6 KB
/
RELEASE-NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
============================================================================
Release notes for BitKeeper version 7.2-oss release May 9 2016
This is the first open source release of BitKeeper. Many changes involve
removing the licensing code.
Changes:
Upgraded TCL/Tk to v8.6 which improved appearance on MacOS.
BitKeeper now uses gfile pathnames in many places where sfile
pathnames were used in the past. The biggest change is that 'bk -r'
returns dir/file instead of dir/SCCS/s.file. Also many error
messages avoid printing SCCS/s.file pathnames since those are
confusing.
The code now uses PCRE for regex code everywhere. This mainly
changes 'bk changes -/regex/' and 'bk log -/regex/'.
Removed old commands:
bk _eula
bk lease
bk legal
bk more
bk status --compat
bk users
Several performance issues related to repositories containing
abnormally large numbers of tags have been fixed.
The BK/Web service has been given significant improvements to upgrade
the appearance from 1998 web standards. ;-)
Changes in individual commands
bk changes
New --lattice && --longest options to change selections based on
the input range.
New --json option to format output for web apps
bk delta
if the last line has no newline at the end and has carriage
returns, they will now be stripped. If no data is left, then the
line is ignored.
The -D option is now limited to RCS diffs. RCS diffs used to not
recognize no newline diffs. They are recognized now.
bk describe
New command to give a friendly name for the current cset like
bk-7.1+183@0x56d9f3c0 (last tag + # of csets since @ time_t of tip)
# Show the tip (and any other csets with that time stamp)
bk changes -c0x56d9f3c0
bk diffs
-h no longer prints a blank first line.
bk fast-export
Add --standalone mode for exporting single components from a
nested collection.
Add support for incremental exports to allow a git repository to
track a bk master.
bk rmgone
Rmgone was completely rewritten and removed a number of bugs and
shortcomings. The new code is nested aware, has a more
understandable output, and won't incorrectly remove some files.
bk makepatch
Makepatch now ONLY generates the bk-5.0 fastpatch format and
later. This breaks pull/push compatibility with bk-4.x, but old
repositories can still be cloned and read. bk clone --upgrade
is your friend.
bk upgrade
Now downloads new versions from the www.bitkeeper.org/downloads area.
This is also used to find the latest release as mentioned by
'bk version'.
Bugs fixed:
Fixed 'bk citool' support for pre-delta triggers. The old behavior
was terrible. (sorry)
'bk changes -R URL' with a bad URL could coredump. Fixed.
'bk chmod' could coredump when run outside a repository.
============================================================================
Release notes for BitKeeper version 7.1 (released Feb 24, 2016)
See our Tips & FAQ page at: http://www.bitkeeper.com/tips
Follow us on Twitter: https://twitter.com/BitKeeper
This release is identical to bk-7.0.3 with one added test to the
repository check for the problem introduced in bk-7.0 which bk-7.0.3
fixed. Since this check could fail on existing repositories the
version was bumped to 7.1.
The most common forms of corruption from this problem will be
automatically and silently repaired by this release if the autofix
config is enabled (on by default). Some more tricky forms are
possible, but we have never seen them in the wild. If these occur,
debugging information to send to [email protected] will be
printed.
The recommendation is to test this release on a couple repositories
before deploying to the team at large.
============================================================================
Release notes for BitKeeper version 7.0.3 (released Feb 17, 2016)
Bugs fixed:
- Return codes fixed to return error, such as when bk check calls itself.
- Fix clock_skew section of config-etc man page. BUG-ID: 2015-12-11-001
- Fix receive and takepatch pulling old style patches into bk-7 repos.
- Fix bug where a post-incoming trigger on a push would eat the first
character after @ in the trigger output.
- Do not delete patch given by bk takepatch -f patch. Abort and resolve did.
- Fix parallel takepatch reading old style patches created by 'bk makepatch'.
- Occasionally force a full repository check when the ChangeSet file
heap has grown significantly and needs garbage collection.
- Change makepatch to send using format of receiving repository.
This reduces conversion data from accumulating in the receiving repo.
============================================================================
Release notes for BitKeeper version 7.0.2 (released Dec 9, 2015)
Bugs fixed:
- bk commit --ci in a nested repository could miss components
that have modified (but not checked in) files
- fix coredump with bk diffs -w
- fix locking issue when running 'bk cset -xREV' in component
- bug related to 'bk diffs -N' when given symlink not under BitKeeper
control
- fix problem where citool could incorrectly strip blank lines from
file comments
GUI Enhancement:
- Add balloon popups to revtool showing revision info
in the following contexts:
- mouse hover over graph nodes
- mouse hover over links in annotation view (press c)
============================================================================
Release notes for BitKeeper version 7.0.1 (released Sep 4, 2015)
Bugs fixed:
- bk version would report an incorrect "Latest version" when a
licenseurl proxy was being used.
- bk status would fail when one of the parents was not readable.
- bk parent would not correctly normalize a Windows (DOS) path.
- Revision controlled symlinks between repositories could cause
'bk sfiles' to fail.
- Reinstate the bk sendbug and support commands (they were
temporarily removed for internal reasons).
- Prevent the text window size tooltips from appearing and
obscuring the comment pane in citool.
Additions:
- Add -S option to bk cset command. This allows users to constrain
including or excluding a cset to the current component.
For example, to exclude the top cset in component A, as opposed to
the whole nested collection
cd componentA; bk cset -S -x+
OS X changes:
- Our minimum supported MacOS version is 10.9 (Mavericks). We do
still build on 10.6 (Snow Leopard) and can supply those images on
request.
- Sign both the application binary and bundle so that the firewall
would not keep asking if it was ok to accept incoming connections.
- Stop putting a config file inside the bundle
(/Applications/BitKeeper.app) and put them in ~/.bk/config
instead. Typically, this config file would only contain the license
keys.
- When upgrading, transfer config contents from the bundle to the new
location.
- Stop using bk links during install. Traditionally, bk links has
been used to install a /usr/bin/bk symlink that points into the
install location. This was handy since it allowed users to use bk
immediately without modifying their PATH. Starting in MacOS 10.11
(el Capitan), writing into /usr is disallowed. Now the installer
will use the path_helper(8) infrastructure to add bk to the
PATH. Since path_helper is run by /etc/profile, users will only see
the updated PATH in new shells.
Emacs users may want to add something like this to their .emacs:
;; get the output of path_helper (which is meant to be interpreted
;; by a shell), remove the MANPATH setting if any, then capture
;; the PATH value and stuff that into the environment
(let ((path (shell-command-to-string "/usr/libexec/path_helper")))
(progn
(setq path (replace-regexp-in-string "^MANPATH=.*$\n" "" path)
path (replace-regexp-in-string
"PATH=\"\\([^;]*\\)\".*\n" "\\1" path))
(setenv "PATH" path)))
============================================================================
Release notes for BitKeeper version 7.0 (released Jul 16, 2015)
This version includes a significant internals rewrite for performance.
The on-disk repository format has changed. You can take advantage of these
changes by replacing your existing repositories with upgraded clones:
bk clone --parents -sTHERE --upgrade existing-repo new-repo
Implications of upgrading
Upgrading some but not all of your repositories can make performance
worse for some operations between repositories of different formats.
The operations will still work. There is a bk clone --downgrade that
goes back to the old ASCII format (somewhat SCCS compatible) that all
versions of BitKeeper support.
Example:
* You have a bkd running bk-7, and have upgraded all the repositories
being served by the bkd.
* You have a user running bk-6 who does a clone.
The bkd will downgrade the repository before sending out clone data, and
the user's bk-6 will upgrade the repository to the new format.
If the user upgrades to the new repository format using bk-7, then neither
of the transformations are done and the clone returns to running quickly.
bk-6 will not be able to access new format repositories directly, but it
can still access them by using a version 7.0 bkd.
Performance changes
-------------------
File format
The ChangeSet file has been reworked for more performance. Operations
that search the history for particular files and/or deltas are significantly
faster. This benefits csettool, revtool, rset, and changes.
bk rset is the utility command used by other commands to expand a
changeset. In a Linux kernel repo:
bk-6.x rset -r+ takes 1243 milliseconds
bk-7.0 rset -r+ takes 90 milliseconds
Commit is also faster:
bk-6.x commit takes 2213 milliseconds
bk-7.0 commit takes 734 milliseconds
The size of your history will determine how much the performance changes
help you; they are geared towards larger repositories with more
changesets and more files.
"checkout: edit" mode
Previously, running in this mode impacted performance of commands
such as 'bk citool'.
Changes were made to how BK stores metadata about editable files
to help it go faster.
An implication of this is that user software that relies on
detecting or examining paths in the form "SCCS/p.file" may not
work as expected. Contact [email protected] if this is a problem.
Performance improvements on NFS
We created a realistic repository simulator and generated a repository
with one million changesets and 230,000 files (4GB of history). We
created identical BitKeeper and Git repositories. We then benchmarked
them on a pair of Intel i7-5930K 6 core/12 thread CPUs, 64GB of ram,
rotating disk. The client file system was NFS version 3 with ext3 as the
backing file system on the server. The benchmark was run on machines
(client and server) with all of the data in cache (if we had done it
cold cache Git looks much worse, Git is optimized for all your data in
memory.)
The results below speak for themselves. Your results may vary, we have
found that on smaller repos, hot cache and/or SSD, Git is comparable to
BK except for things that search the history (bk annotate, bk grep) or
the integrity check. BK is much much faster when you are looking
through the history and is much faster for an integrity check or garbage
collection. If you are using BK/Nested the performance wins are even
larger.
Truth in advertising: the diff changed files is only that fast if you
run in checkout:get - that mode lets us remember each file you edited
and not scan the whole tree. That's why we suggest checkout:get for
really large trees.
What BK GIT How much faster is BK?
----------------------------------------------------------------------------
simulate 1M csets 7.5 hours 165 hours 22 times faster
clone 210 seconds 338 seconds 1.6 times faster
clone 1 component 6.5 seconds N.A. N.A
list changed files 0.3 seconds 40.6 seconds 135 times faster
diff changed files 0.9 seconds 34.6 seconds 38 times faster
commit 4.8 seconds 42.5 seconds 9 times faster
changes -R 0.6 seconds 21.6 seconds 36 times faster
update-only pull 7.3 seconds 42.3 seconds 6 times faster
log of 1 file 0.01 seconds 1.6 seconds 160 times faster
annotate/blame 0.01 seconds 32.3 seconds 3230 times faster
search history 0.01 seconds 138.9 seconds 13890 times faster
integrity check 206.5 seconds 6576.2 seconds 32 times faster
New features
------------
bk annotate
Added -w option to show "who deleted" annotations.
bk bisect
New command to help find a changeset that introduced a bug.
bk commit --ci
Check in edited files as part of a commit.
bk csets
New option --stats that prints statistics about what was pulled.
bk -j<arg> cmd
The -j option to 'bk' has changed. In bk-6.x and earlier it
would list 'junk' files (extra files in the SCCS directory). This
is files in bk's internal storage space that were not written by bk.
This was deemed not useful and so the command line option was reused
for an internal option.
bk config <var>
This used to show what <var> was set to in a config file.
If <var> wasn't in any config file, then nothing would be shown.
This now shows the default value for <var>.
bk config -v
This command now shows the default values for all config variables.
The following defaults have changed:
autofix now defaults to "on"
parallel now defaults to "on"
bk findmerge
New command for showing which cset was the first to merge two
other csets.
bk fm3tool
Added "who deleted" annotation when you turn on annotations.
Uses the "who deleted" information to show the delta comments
for the delta that did the delete in the comments window (formerly it
showed the delta that added the deleted line, which is far
less useful).
bk partition
New option --keep-deleted that does not prune out the deleted history
as part of the partition.
bk pull
New option --stats that prints statistics about what was pulled.
It can also be permanently enabled by setting the
config variable stats_after_pull to "on".
Fix a bug where pull was not disallowing the -R option with
multiple parents or URLs.
bk repocheck
Now runs in parallel automatically when used on a nested collection.
On a fast machine this can be about a 6x speedup (hot cache) and
13x speedup (cold cache, SSD).
bk repos
New command to show a list of your repositories.
bk revtool
Added "who deleted" annotation.
bk rset
Rewritten to be faster on traditional repositories, and massively
faster on new format repositories.
bk setup
No longer interactive by default. Running 'bk setup' will now turn
the current working directory into a new BitKeeper repository.
bk status
The old 'bk status' output wasn't very useful so the command was
rewritten to provide more useful information about the current
repository status.
See 'bk help status' for details.
bk tag
The rules for valid tags names have been restricted to more normal
looking identifiers to avoid compatibility issues in the future.
See 'bk help tag' for the new rules.
Existing tags that break these rules will continue to be supported
but new tags need to follow the new rules.
bk takepatch
An internal command used by pull. Enhanced to do resolve automerging
in cases where only content merging needs to be done. Enhanced with
parallel operation, meaning each file-patch and automerge is handled
in a sub-process.
Bugfixes
--------
- 'bk cset -x' works in a BK/Nested product.
- 'bk cp' now correctly handles BAM binary files.
- Several more tricky merge conflicts are now handled automatically.
- 'bk collapse' now preserves file deltas that exclude other deltas.
- 'bk lock -w' in non-nested was terminating before lock was fully released.
- Fix failures caused by extremely long filenames or extremely large
repositories.
- 'bk rset -r$MERGE_CSET' now correctly lists merge revisions of files.
Platforms
---------
Minimum Windows version supported is Windows Vista.
We continue to support Linux, Windows, MacOS, Solaris, and several
BSDs on x86. We can add back in any other major platform if needed,
just let us know.