/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/interrupted.txt

  • Committer: Martin Pool
  • Date: 2005-06-28 03:02:31 UTC
  • Revision ID: mbp@sourcefrog.net-20050628030231-d311e4ebcd467ef4
Merge John's import-speedup branch:

                                                                                         
  777 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:20:32 -0500
      revision-id: john@arbash-meinel.com-20050627032031-e82a50db3863b18e
      bzr selftest was not using the correct bzr

  776 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:20:22 -0500
      revision-id: john@arbash-meinel.com-20050627032021-c9f21fde989ddaee
      Add was using an old mutter

  775 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 22:02:33 -0500
      revision-id: john@arbash-meinel.com-20050627030233-9165cfe98fc63298
      Cleaned up to be less different

  774 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:54:53 -0500
      revision-id: john@arbash-meinel.com-20050627025452-4260d0e744edef43
      Allow BZR_PLUGIN_PATH='' to negate plugin loading.

  773 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:49:34 -0500
      revision-id: john@arbash-meinel.com-20050627024933-b7158f67b7b9eae5
      Finished the previous cleanup (allowing load_plugins to be called twice)

  772 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:45:08 -0500
      revision-id: john@arbash-meinel.com-20050627024508-723b1df510d196fc
      Work on making the tests pass. versioning.py is calling run_cmd directly, but plugins have been loaded.

  771 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:32:29 -0500
      revision-id: john@arbash-meinel.com-20050627023228-79972744d7c53e15
      Got it down a little bit more by removing import of tree and inventory.

  770 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 21:26:05 -0500
      revision-id: john@arbash-meinel.com-20050627022604-350b9773ef622f95
      Reducing the number of import from bzrlib/__init__.py and bzrlib/branch.py

  769 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:32:25 -0500
      revision-id: john@arbash-meinel.com-20050627013225-32dd044f10d23948
      Updated revision.py and xml.py to include SubElement.

  768 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:03:56 -0500
      revision-id: john@arbash-meinel.com-20050627010356-ee66919e1c377faf
      Minor typo

  767 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 20:03:13 -0500
      revision-id: john@arbash-meinel.com-20050627010312-40d024007eb85051
      Caching the import

  766 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:51:47 -0500
      revision-id: john@arbash-meinel.com-20050627005147-5281c99e48ed1834
      Created wrapper functions for lazy import of ElementTree

  765 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:46:37 -0500
      revision-id: john@arbash-meinel.com-20050627004636-bf432902004a94c5
      Removed all of the test imports of cElementTree

  764 John Arbash Meinel <john@arbash-meinel.com>       Sun 2005-06-26 19:43:59 -0500
      revision-id: john@arbash-meinel.com-20050627004358-d137fbe9570dd71b
      Trying to make bzr startup faster.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/interrupted.txt
 
1
Interrupted operations
 
2
**********************
 
3
 
 
4
Problem: interrupted operations
 
5
===============================
 
6
 
 
7
Many version control systems tend to have trouble when operations are
 
8
interrupted.  This can happen in various ways:
 
9
 
 
10
 * user hits Ctrl-C
 
11
 
 
12
 * program hits a bug and aborts
 
13
 
 
14
 * machine crashes
 
15
 
 
16
 * network goes down
 
17
 
 
18
 * tree is naively copied (e.g. by cp/tar) while an operation is in
 
19
   progress
 
20
 
 
21
We can reduce the window during which operations can be interrupted:
 
22
most importantly, by receiving everything off the network into a
 
23
staging area, so that network interruptions won't leave a job half
 
24
complete.  But it is not possible to totally avoid this, because the
 
25
power can always fail.
 
26
 
 
27
I think we can reasonably rely on flushing to stable storage at
 
28
various points, and trust that such files will be accessible when we
 
29
come back up.
 
30
 
 
31
I think by using this and building from the bottom up there are never
 
32
any broken pointers in the branch metadata: first we add the file
 
33
versions, then the inventory, then the revision and signature, then
 
34
link them into the revision history.  The worst that can happen is
 
35
that there will be some orphaned files if this is interrupted at any
 
36
point. 
 
37
 
 
38
rsync is just impossible in the general case: it reads the files in a
 
39
fairly unpredictable order, so what it copies may not be a tree that
 
40
existed at any particular point in time.  If people want to make
 
41
backups or replicate using rsync they need to treat it like any other
 
42
database and either
 
43
 
 
44
 * make a copy which will not be updated, and rsync from that
 
45
 
 
46
 * lock the database while rsyncing
 
47
 
 
48
The operating system facilities are not sufficient to protect against
 
49
all of these.  We cannot satisfactorily commit a whole atomic
 
50
transaction in one step.
 
51
 
 
52
Operations might be updating either the metadata or the working copy.
 
53
 
 
54
The working copy is in some ways more difficult:
 
55
 
 
56
 * Other processes are allowed to modify it from time to time in
 
57
   arbitrary ways.
 
58
 
 
59
   If they modify it while bazaar is working then they will lose, but
 
60
   we should at least try to make sure there is no corruption.
 
61
 
 
62
 * We can't atomically replace the whole working copy.  We can
 
63
   (semi) atomically updated particular files.
 
64
 
 
65
 * If the working copy files are in a weird state it is hard to know
 
66
   whether that occurred because bzr's work was interrupted or because
 
67
   the user changed them.
 
68
 
 
69
   (A reasonable user might run ``bzr revert`` if they notice
 
70
   something like this has happened, but it would be nice to avoid
 
71
   it.)
 
72
 
 
73
We don't want to leave things in a broken state.
 
74
 
 
75
 
 
76
Solution: write-ahead journaling?
 
77
=================================
 
78
 
 
79
One possibly solution might be write-ahead journaling:
 
80
 
 
81
  Before beginning a change, write and flush to disk a description of
 
82
  what change will be made.
 
83
 
 
84
  Every bzr operation checks this journal; if there are any pending
 
85
  operations waiting then they are completed first, before proceeding
 
86
  with whatever the user wanted.  (Perhaps this should be in a
 
87
  separate ``bzr recover``, but I think it's better to just do it,
 
88
  perhaps with a warning.)
 
89
 
 
90
  The descriptions written into the journal need to be simple enough
 
91
  that they can safely be re-run in a totally different context.  They
 
92
  must not depend on any external resources which might have gone
 
93
  away.
 
94
 
 
95
  If we can do anything without depending on journalling we should.
 
96
 
 
97
  It may be that the only case where we cannot get by with just
 
98
  ordering is in updating the working copy; the user might get into a
 
99
  difficult situation where they have pulled in a change and only half
 
100
  the working copy has been updated.  One solution would be to remove
 
101
  the working copy files, or mark them readonly, while this is in
 
102
  progress.  We don't want people accidentally writing to a file that
 
103
  needs to be overwritten.
 
104
 
 
105
  Or perhaps, in this particular case, it is OK to leave them in
 
106
  pointing to an old state, and let people revert if they're sure they
 
107
  want the new one?  Sounds dangerous.
 
108
 
 
109
Aaron points out that this basically sounds like changesets.  So
 
110
before updating the history, we first calculate the changeset and
 
111
write it out to stable storage as a single file.  We then apply the
 
112
changeset, possibly updating several files.  Each command should check
 
113
whether such an application was in progress.