/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/gc.txt

  • Committer: Robert Collins
  • Date: 2006-09-11 01:03:59 UTC
  • mto: This revision was merged to the branch mainline in revision 2019.
  • Revision ID: robertc@robertcollins.net-20060911010359-0404571fa92c5cfe
``Branch.bind(other_branch)`` no longer takes a write lock on the
other branch, and will not push or pull between the two branches.
API users will need to perform a push or pull or update operation if they
require branch synchronisation to take place. (Robert Collins)

``bzr bind`` no longer synchronises history with the master branch.
Binding should be followed by an update or push to synchronise the 
two branches. This fixes bug #39542 for heavyweight checkouts.
(Robert Collins)

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
Garbage Collection
2
 
==================
3
 
 
4
 
Garbage collection is used to remove data from a repository that is no longer referenced.
5
 
 
6
 
Generally this involves locking the repository and scanning all its branches
7
 
then generating a new repository with less data.
8
 
 
9
 
Least work we can hope to perform
10
 
---------------------------------
11
 
 
12
 
* Read all branches to get initial references - tips + tags.
13
 
* Read through the revision graph to find unreferenced revisions. A cheap HEADS
14
 
  list might help here by allowing comparison of the initial references to the
15
 
  HEADS - any unreferenced head is garbage.
16
 
* Walk out via inventory deltas to get the full set of texts and signatures to preserve.
17
 
* Copy to a new repository
18
 
* Bait and switch back to the original
19
 
* Remove the old repository.
20
 
 
21
 
A possibility to reduce this would be to have a set of grouped 'known garbage
22
 
free' data - 'ancient history' which can be preserved in total should its HEADS
23
 
be fully referenced - and where the HEADS list is deliberate cheap (e.g. at the
24
 
top of some index).
25
 
 
26
 
possibly - null data in place without saving size.