← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/split-join-files.txt

  • Committer: Robert Collins
  • Date: 2005-10-29 23:48:45 UTC
  • Revision ID: robertc@robertcollins.net-20051029234845-7ae4e7d118bdd3ed
Implement a 'bzr push' command, with saved locations; update diff to return 1.

    * 'bzr diff' now returns 1 when there are changes in the working 
      tree.

    * 'bzr push' now exists and can push changes to a remote location. 
      This uses the transport infrastructure, and can store the remote
      location in the ~/.bazaar/branches.conf configuration file.

    * WorkingTree.pull has been split across Branch and WorkingTree,
      to allow Branch only pulls.

    * commands.display_command now returns the result of the decorated 
      function.

    * LocationConfig now has a set_user_option(key, value) call to save
      a setting in its matching location section (a new one is created
      if needed).

    * Branch has two new methods, get_push_location and set_push_location
      to respectively, get and set the push location.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/split-join-files.txt
 
1
Split and join files
 
2
====================
 
3
 
 
4
Version control systems tend to have trouble when files are split or
 
5
joined.  Here is one possibility for handling that.
 
6
 
 
7
 
 
8
Splitting files
 
9
---------------
 
10
 
 
11
This can work like 'svn cp': copy with history::
 
12
 
 
13
  % bzr cp a b
 
14
 
 
15
This creates a new file b, whose file-history is the same as a, but
 
16
with a different file-id, and present at a different name.
 
17
 
 
18
This creates the slightly strange situation that b claims to have text
 
19
versions for revisions where b was not actually present.
 
20
 
 
21
 
 
22
Joining files
 
23
-------------
 
24
 
 
25
We might want to also join files in various cases:
 
26
 
 
27
 * Multiple imports of the same file
 
28
 
 
29
 * Two source files are being refactored into a single one
 
30
 
 
31
 * Two people apply an external patch that creates the same file
 
32
 
 
33
I'm not aware of any other system that handles this.
 
34
 
 
35
  % bzr join a b
 
36
 
 
37
a and b must be versioned files.  b is removed from the working tree
 
38
and inventory.  b's file id is added as a secondary id as a, so that
 
39
later merges between them will detect them as being the same.  
 
40
 
 
41
b's weave is (???) incorporated into a.  
 
42
 
 
43
This means that we have a file which has multiple history paths.  For
 
44
example, asking to compare that file to its state in a previous
 
45
version has to arbitrarily pick one to use.  That's not necessarily
 
46
fatal if we assign one as primary, but it might be a bit confusing.
 
47
Trying to merge from another tree might can't really choose a good
 
48
basis.
 
49
 
 
50
 
 
51
 
 
52
File aliases
 
53
------------
 
54
 
 
55
Rather than trying to join files we might just add notes that files
 
56
are also known by a different file-id in other trees.
 
57
 
 
58
 
 
59