← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/use-cases.txt

  • Committer: Patch Queue Manager
  • Date: 2012-01-18 16:23:31 UTC
  • mfrom: (6439.1.1 work)
  • Revision ID: pqm@pqm.ubuntu.com-20120118162331-md4sf1tw6hyuw344
(vila) Ensure people get an easy access to the release details from
 announcements. (Vincent Ladeuil)

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?