~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/commit.txt

  • Committer: Tarmac
  • Author(s): Vincent Ladeuil
  • Date: 2017-01-30 14:42:05 UTC
  • mfrom: (6620.1.1 trunk)
  • Revision ID: tarmac-20170130144205-r8fh2xpmiuxyozpv
Merge  2.7 into trunk including fix for bug #1657238 [r=vila]

Show diffs side-by-side

added added

removed removed

Lines of Context:
174
174
     happened several commits back. There are several edge cases to be
175
175
     handled here, like if both branches modified the same file, or if
176
176
     just one branch modified it.
177
 
     
 
177
 
178
178
  b) The trickier case is when a file appears unmodified since last
179
179
     commit, but it was modified versus one of the merged branches. I
180
180
     believe there are a few ways this can happen, like if a merged
291
291
It is desirable to avoid roundtrips to the Repository during commit,
292
292
particularly because it may be remote.  If the WorkingTree can determine
293
293
by itself that a text was in the parent and therefore should be in the
294
 
Repository that avoids one roundtrip per file.  
 
294
Repository that avoids one roundtrip per file.
295
295
 
296
296
There is a possibility here that the parent revision is not stored, or not
297
297
correctly stored, in the repository the tree is being committed into, and
311
311
This creates a CommitBuilder object matched to the Branch, Repository and
312
312
Tree.  It can vary depending on model differences or by knowledge of what
313
313
is efficient with the Repository and Tree.  Model differences might
314
 
include whether no-text-change merges need to be reported, and whether the 
 
314
include whether no-text-change merges need to be reported, and whether the
315
315
 
316
 
The basic CommitBuilder.commit structure can be 
 
316
The basic CommitBuilder.commit structure can be
317
317
 
318
318
1. Ask the branch if it is ready to commit (up to date with master if
319
319
   any.)
358
358
 
359
359
* the working tree basis is up to date with the branch tip
360
360
 
361
 
* the local branch is up to date with the master branch, if there 
 
361
* the local branch is up to date with the master branch, if there
362
362
  is one and --local is not specified
363
363
 
364
 
* an empty commit message is given, 
 
364
* an empty commit message is given,
365
365
 
366
366
* a hook flags an error
367
367
 
396
396
* if there are tree references and recursing into them is enabled, then
397
397
  do so
398
398
 
399
 
Commit needs to protect against duplicated file ids 
 
399
Commit needs to protect against duplicated file ids
400
400
 
401
401
 
402
402
Updates that need to be made in the working tree, either on conclusion
429
429
* or an indication that it should be read interactively from the ui object;
430
430
* a list of files to commit
431
431
* an option for a dry-run commit
432
 
* verbose option, or callback to indicate 
 
432
* verbose option, or callback to indicate
433
433
* timestamp, timezone, committer, chosen revision id
434
434
* config (for what?)
435
435
* option for local-only commit on a bound branch
436
436
* option for strict commits (fail if there are unknown or missing files)
437
437
* option to allow "pointless" commits (with no tree changes)
438
 
 
 
438
 
439
439
(This is rather a lot of options to pass individually and just for code tidyness maybe some of them should be combine into objects.)
440
440
 
441
441
>>> Branch.commit(from_tree, message, files_to_commit, ...)
466
466
This needs to collect a list of added/changed/removed files, each of which
467
467
must have its text stored (if any) and containing directory updated.  This
468
468
can be done by calling Tree._iter_changes on the source tree, asking for
469
 
changes 
 
469
changes
470
470
 
471
471
In the 0.17 model the commit operation needs to know the per-file parents
472
 
and per-file last-changed revision.  
 
472
and per-file last-changed revision.
473
473
 
474
474
(In this and other operations we must avoid having multiple layers walk
475
475
over the tree separately.  For example, it is no good to have the Command
530
530
The main things the tree needs to tell the Branch about are:
531
531
 
532
532
* A file is modified from its parent revision (in text, permissions,
533
 
  other), and so its text may need to be stored.  
534
 
  
 
533
  other), and so its text may need to be stored.
 
534
 
535
535
  Files should also be reported if they have more than one unique parent
536
536
  revision, for repositories that store per-file graphs or last-change
537
537
  revisions.  Perhaps this behaviour should be optional.
540
540
 
541
541
* The complete contents of a modified directory, so that its inventory
542
542
  text may be stored.  This should be done after all the contained files
543
 
  and directories have been reported.  If there are unmodified files, 
544
 
  or unselected files carried through from 
 
543
  and directories have been reported.  If there are unmodified files,
 
544
  or unselected files carried through from
545
545
 
546
 
  XXX: Actually perhaps not grouped by directory, but rather grouped 
547
 
  appropriately for the shape of inventory storage in the repository. 
 
546
  XXX: Actually perhaps not grouped by directory, but rather grouped
 
547
  appropriately for the shape of inventory storage in the repository.
548
548
 
549
549
  In a zoomed-in checkout the workingtree may not have all the shape data
550
550
  for the entire tree.
577
577
This might be construed as an enhanced version of ``set_parent_trees``.
578
578
We can avoid a stat on each file by using the value that was observed when
579
579
it was first read.
580
 
 
 
580
 
581
581
 
582
582
 
583
583
Selective commit
591
591
However, the tree walking code does probably need to know about selected
592
592
paths to avoid examining unselected files or directories.
593
593
 
594
 
We never refuse selective file commits (except of merges).  
 
594
We never refuse selective file commits (except of merges).
595
595
 
596
596
 
597
597