← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/incremental-push-pull.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-06-04 06:29:25 UTC
  • mfrom: (2485.4.8 roadmap)
  • Revision ID: pqm@pqm.ubuntu.com-20070604062925-0a2e6fvr3qpfngzo
(robertc) More London sprint documentation

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/incremental-push-pull.txt
240
240
transmission method to reasonably closely match the desired write ordering
241
241
locally. This suggests that once we decide on the best local storage means we
242
242
should design the api.
 
243
 
 
244
 
 
245
take N commits from A to B, if B is local then merge changes into the tree.
 
246
copy ebough data to recreate snapshots
 
247
avoid ending up wth corrupt/bad data
 
248
 
 
249
Notes from London
 
250
=================
 
251
 
 
252
 #. setup
 
253
 
 
254
   look at graph of revisions for ~N comits to deretmine eligibility for 
 
255
   if preserve mainline is on, check LH only
 
256
 
 
257
    identify objects to send that are not on the client repo
 
258
      - revision - may be proportional to the graph
 
259
      - inventory - proportional to work
 
260
      - texts     - proportional to work
 
261
      - signatures - ???
 
262
 
 
263
 #. data transmission
 
264
 
 
265
  * send data proportional to the new information
 
266
  * validate the data:
 
267
 
 
268
   #. validate the sha1 of the full text of each transmitted text.
 
269
   #. validate the sha1:name mapping in each newly referenced inventory item.
 
270
   #. validate the sha1 of the XML of each inventory against the revision.
 
271
      *** this is proportional to tree size and must be fixed ***
 
272
 
 
273
 #. write the data to the local repo.
 
274
    The API should output the file texts needed by the merge as by product of the transmission
 
275
 
 
276
 #. tree application
 
277
 
 
278
Combine the output from the transmission step with additional 'new work data' for anything already in the local repository that is new in this tree.
 
279
should write new files and stat existing files proportional to the count of the new work and the size of the full texts.