/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/en/user-guide/adv_merging.txt

  • Committer: John Arbash Meinel
  • Date: 2007-12-13 20:17:06 UTC
  • mto: This revision was merged to the branch mainline in revision 3121.
  • Revision ID: john@arbash-meinel.com-20071213201706-nt8f4om80gyn6l6v
Fix LockableFiles to not use modes that allow the user to write to things they create.
It seems that cygwin + FAT32 will report all directories as readonly,
even though they are not.
Regardless, someone might have .bzr/repository as readonly, but still
allow you to create files in a subdirectory.
Either way, there is no reason to have a file that we are going to
write to be created readonly.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/user-guide/adv_merging.txt
1
 
Pseudo merging
2
 
==============
 
1
Advanced merging
 
2
================
3
3
 
4
4
Cherrypicking
5
5
-------------
47
47
be done at a later time. In other cases, additional conflicts will need
48
48
to be resolved when the changes are merged again.
49
49
 
50
 
Merging without parents
51
 
-----------------------
52
 
 
53
 
A related technique to cherrypicking, in that it makes changes without
54
 
reference to the revisions that they came from is to perform a merge, but
55
 
forget about the parent revisions before committing.  This has the effect of
56
 
making all of the changes that would have been in the merge happen in a single
57
 
commit.  After the merge and before the corresponding commit, you can do::
58
 
 
59
 
  bzr revert --forget-merges
60
 
 
61
 
to keep the changes in the working tree, but remove the record of the
62
 
revisions where the changes originated.  The next commit would then record
63
 
all of those changes without any record of the merged revisions.
64
 
 
65
 
This is desired by some users to make their history "cleaner", but you should
66
 
be careful that the loss of history does not outweigh the value of cleanliness,
67
 
particularly given Bazaar's capabilities for progressively disclosing merged
68
 
revisions.  In particular, because this will include the changes from the
69
 
source branch, but without attribution to that branch, it can lead to
70
 
additional conflicts on later merges that involve the same source and
71
 
target branches.
 
50
Note: The reason why Bazaar doesn't track cherrypicks yet is that doing so
 
51
can lead to poor performance. We are exploring ways of tracking
 
52
this information that perform acceptably and hope to improve Bazaar's
 
53
cherrypicking support in the future accordingly.
72
54
 
73
55
 
74
56
Reverse cherrypicking
87
69
Merging uncommitted changes
88
70
---------------------------
89
71
 
90
 
If you have several branches and you accidentally start making changes in the
 
72
If you have several branches and you accidently start making changes in the
91
73
wrong one, here are the steps to take to correct this. Assuming you began
92
74
working in branch ``foo`` when you meant to work in branch ``bar``:
93
75
 
131
113
Note: Some users coming from central VCS tools with poor merge tracking
132
114
like rebasing because it's similar to how they are use to working in older
133
115
tools, or because "perfectly clean" history seems important. Before rebasing
134
 
in Bazaar, think about whether a normal merge is a better choice. In
135
 
particular, rebasing a private branch before sharing it is OK but
136
 
rebasing after sharing a branch with someone else is **strongly** discouraged.
 
116
in Bazaar, think about whether a normal merge is a better choice.