← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/use-cases.txt

  • Committer: Robert Collins
  • Date: 2005-10-19 10:11:57 UTC
  • mfrom: (1185.16.78)
  • mto: This revision was merged to the branch mainline in revision 1470.
  • Revision ID: robertc@robertcollins.net-20051019101157-17438d311e746b4f
merge from upstream

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/use-cases.txt
 
1
Bazaar-NG Use Cases
 
2
*******************
 
3
 
 
4
.. contents::
 
5
 
 
6
 
 
7
 
 
8
Review changes 
 
9
==============
 
10
 
 
11
Look at somebody else's tree or email submissions.  
 
12
 
 
13
Looking at the patch alone may not be enough; we might need to apply
 
14
it to a tree, build it and see if we like it.
 
15
 
 
16
 
 
17
 
 
18
 
 
19
Changes on branches
 
20
===================
 
21
 
 
22
Clearcase allows you to put all new development onto branches that are
 
23
later merged back.
 
24
 
 
25
Can we detect which development branches have unmerged changes?  Can
 
26
we dispose of those branches?
 
27
 
 
28
 
 
29
 
 
30
unmerge
 
31
=======
 
32
 
 
33
Get rid of any changes that have been merged in but not yet
 
34
committed.  Shouldn't this just be ``bzr revert``?
 
35
 
 
36
 
 
37
 
 
38
cross damage problem with PQM 
 
39
=============================
 
40
 
 
41
Lock 
 
42
 
 
43
 
 
44
 
 
45
undo some uncommitted changes
 
46
=============================
 
47
 
 
48
If you've made some changes and don't want them::
 
49
 
 
50
  baz undo foo.c
 
51
 
 
52
This stores them as a changeset in a directory that you can move
 
53
around.  You can set a name for it::
 
54
 
 
55
  baz undo --name blargh-refactor foo.c bar.c
 
56
 
 
57
You can get it back::
 
58
 
 
59
  baz redo foo.c
 
60
 
 
61
 
 
62
move some in-progress changes onto a local branch
 
63
=================================================
 
64
 
 
65
This is useful if we decide some changes on a bound branch should be
 
66
done on a separate branch; in particular people will want to do this
 
67
if they want to work in only one subdirectory of a complex config.
 
68
 
 
69
Possibly this should be the default with no arguments for ``bzr
 
70
branch``.  Or possibly there should be a separate ``bzr unbind``.
 
71
 
 
72
 
 
73
 
 
74
ignore some files
 
75
=================
 
76
 
 
77
I'm working on a Python project, which leaves bytecode files in the
 
78
working directory::
 
79
 
 
80
  baz ignore \*.pyc
 
81
  baz ignore \*.pyo
 
82
 
 
83
or::
 
84
 
 
85
  baz ignore '*.py[co]'
 
86
 
 
87
OK, there is some danger here that people always forget to quote globs
 
88
on the command line but maybe this will be enough.
 
89
 
 
90
Maybe take only one at a time so that we can catch unquoted globs like
 
91
this::
 
92
 
 
93
  baz ignore *.pyc                      # wrong!
 
94
 
 
95
If they do this, they see all '* added foo.pyc to .arch-inventory';
 
96
then they can do this to get back::
 
97
 
 
98
  baz undo .arch-inventory
 
99
 
 
100
This is potentially much more pleasant than Subversion.
 
101
 
 
102
 
 
103
 
 
104
Wrong commit message
 
105
====================
 
106
 
 
107
I accidentally commit some files with the wrong message and want to
 
108
change them::
 
109
 
 
110
   % bzr status
 
111
   M    foo.c
 
112
   % bzr commit -s 'fix foo'
 
113
   M    foo.c
 
114
   [oops!]
 
115
   % bzr uncommit
 
116
   % bzr status
 
117
   M    foo.c
 
118
   % bzr commit -s 'fix foo and bar'
 
119
 
 
120
This fix should be done as soon as possible, before anything else
 
121
depends on the change.
 
122
   
 
123
 
 
124
 
 
125
Monday morning
 
126
==============
 
127
 
 
128
Come in Monday morning; can't remember what you were doing.
 
129
 
 
130
* log; look at what was committed
 
131
* diff against upstream, or recent revisions
 
132
* what else?