~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/random.txt

- rules for using destructors

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
I think Ruby's point is right: we need to think about how a tool
 
2
*feels* as you're using it.
 
3
 
 
4
Making regular commits gives a nice rhythm to to working; in some
 
5
ways it's nicer to just commit single files with C-x v v than to build
 
6
complex changesets.  (See gmane.c.v-c.arch.devel post 19 Nov, Tom
 
7
Lord.)
 
8
 
 
9
 
 
10
* Would like to generate an activity report, to e.g. mail to your boss
 
11
  or post to your blog.  "What did I change today, across all these
 
12
  specified branches?"
 
13
 
 
14
 
 
15
* It is possibly nice that tla by default forbids you from committing
 
16
  if emacs autosave or lock files exist -- I find it confusing to
 
17
  commit somethin other than what is shown in the editor window
 
18
  because there are unsaved changes. 
 
19
 
 
20
  However, grumbling about unknown files is annoying, and requiring
 
21
  people to edit regexps in the id-tagging-method file to fix it is
 
22
  totally unreasonable.
 
23
 
 
24
  Perhaps there should be a preference to abort on unknown files, or
 
25
  perhaps it should be possible to specify forbidden files.
 
26
 
 
27
  Perhaps this is related to a mechanism to detect conflicted files:
 
28
  should refuse to commit if there are any .rej files lying around.
 
29
 
 
30
 
 
31
 
 
32
   *Those who lose history are doomed to recreate it.*
 
33
         -- broked (on #gnu.arch.users)
 
34
 
 
35
   *A universal convention supplies all of maintainability, clarity, consistency, and a foundation for good programming habits too. What it doesn't do is insist that you follow it against your will. That's Python!*
 
36
 
 
37
    -- Tim Peters on comp.lang.python, 2001-06-16
 
38
 
 
39
    (Bazaar provides mechanism and convention, but it is up to you
 
40
    whether you wish to follow or enforce that convention.)
 
41
 
 
42
----
 
43
 
 
44
jblack asks for 
 
45
 
 
46
   A way to subtract merges, so that you can see the work you've done
 
47
   to a branch since conception.
 
48
 
 
49
----
 
50
 
 
51
:: 
 
52
 
 
53
  <mpool> now that is a neat idea: advertise branches over zeroconf
 
54
  <mpool> should make lca fun :-)
 
55
 
 
56
----
 
57
 
 
58
http://thedailywtf.com/ShowPost.aspx?PostID=24281
 
59
 
 
60
  Source control is necessary and useful, but in a team of one (or even two) people the setup overhead isn't always worth it--especially if you're going to join source control in a month, and you don't want to have to migrate everything out of your existing (in my case, skunkworks) system before you can use it.
 
61
 
 
62
  At least that was my experience--I putzed with CVS a bit and knew other source control systems pretty well, but in the day-to-day it wasn't worth the bother (granted, I was a bit offended at having to wait to use the mainline source control, but that's another matter).
 
63
 
 
64
I think Bazaar-NG will have such low setup overhead (just ``init``,
 
65
``add``) that it can be easily used for even tiny projects.  The
 
66
ability to merge previously-unrelated trees means they can fold their
 
67
project in later.
 
68
 
 
69
 
 
70
----
 
71
 
 
72
From tridge:
 
73
 
 
74
* cope without $EMAIL better
 
75
 
 
76
* notes at start of .bzr.log:
 
77
  * you can delete this
 
78
  * or include it in bug reports
 
79
 
 
80
* should you be able to remove things from the default ignore list?
 
81
 
 
82
* headers at start of diff, giving some comments, perhaps dates
 
83
 
 
84
  * is diff against /dev/null really OK?  I think so.
 
85
 
 
86
* separate remove/delete commands?  
 
87
 
 
88
* detect files which were removed and now in 'missing' state
 
89
 
 
90
* should we actually compare files for 'status', or check mtime and
 
91
  size; reading every file in the samba source tree can take a long
 
92
  time.
 
93
 
 
94
  without this, doing a status on a large tree can be very slow.  but
 
95
  relying on mtime/size is a bit dangerous.
 
96
 
 
97
  people really do work on trees which take a large chunk of memory
 
98
  and which will not stay in memory
 
99
 
 
100
* status up-to-date files: not 'U', and don't list without --all
 
101
 
 
102
* if status does compare file text, then it should be quick when
 
103
  checking just a single file
 
104
 
 
105
* wrapper for svn that every time run logs
 
106
 
 
107
  - command
 
108
  - all inputs
 
109
  - time it took
 
110
  - sufficient to replay everything
 
111
  - record all files
 
112
 
 
113
* status crashes if a file is missing
 
114
 
 
115
* option for -p1 level on diff, etc.  perhaps
 
116
 
 
117
* commit without message should start $EDITOR
 
118
 
 
119
* don't duplicate all files on commit
 
120
 
 
121
* start importing tridge-junkcode
 
122
 
 
123
* perhaps need xdelta storage sooner rather than later, to handle very
 
124
  large file
 
125
 
 
126
----
 
127
 
 
128
The first operation most people do with a new version-control system
 
129
is *not* making their own project, but rather getting a checkout of an
 
130
existing project, building it, and possibly submitting a patch.  So
 
131
those operations should be *extremely* easy.
 
132
 
 
133
----
 
134
 
 
135
* Way to check that a branch is fully merged, and no longer needed:
 
136
  should mean all its changes have been integrated upstream, no
 
137
  uncommitted changes or rejects or unknown files.
 
138
 
 
139
* Filter revisions by containing a particular word (as for log).
 
140
  Perhaps have key-value fields that might be used for
 
141
  e.g. line-of-development or bug nr?
 
142
 
 
143
* List difference in the revisions on one branch vs another.
 
144
 
 
145
* Perhaps use a partially-readable but still hopefully unique ID for
 
146
  revisions/inventories?
 
147
 
 
148
* Preview what will happen in a merge before it is applied
 
149
 
 
150
* When a changeset deletes a file, should have the option to just make
 
151
  it unknown/ignored.
 
152
 
 
153
  Perhaps this is best handled by an interactive merge.  If the file
 
154
  is unchanged locally and deleted remotely, it will by default be
 
155
  deleted (but the user has the option to reject the delete, or to
 
156
  make it just unversioned, or to save a copy.)  If it is modified
 
157
  locall then the user still needs to choose between those options but
 
158
  there is no default (or perhaps the default is to reject the delete.)
 
159
 
 
160
* interactive commit, prompting whether each hunk should be sent (as
 
161
  for darcs)
 
162
 
 
163
* Write up something about detection of unmodified files
 
164
 
 
165
* Preview a merge so as to get some idea what will happen:
 
166
 
 
167
  * What revisions will be merged (log entries, etc)
 
168
 
 
169
  * What files will be affected?
 
170
 
 
171
  * Are those simple updates, or have they been updated locally as
 
172
    well.
 
173
 
 
174
  * Any renames or metadata clashes?
 
175
 
 
176
  * Show diffs or conflict markers.
 
177
 
 
178
  * Do the merge, but write into a second directory.
 
179
 
 
180
* "Show me all changesets that touch this file"
 
181
 
 
182
  Can be done by walking back through all revisions, and filtering out
 
183
  those where the file-id either gets a new name or a new text.  
 
184
 
 
185
* Way to commit backdated revisions or pretend to be something by
 
186
  someone else, for the benefit of import tools; in general allow
 
187
  everything taken from the current environment to be overridden.
 
188
 
 
189
* Cope well when trying to checkout or update over a flaky
 
190
  connection.  Passive HTTP possibly helps with this: we can fetch all
 
191
  the file texts first, then the inventory, and can even retry
 
192
  interrupted connections.
 
193
 
 
194
* Use readline for reading log messages, and store a history of
 
195
  previous commit messages!
 
196
 
 
197
* Warn when adding huge files(?) - more than say 10MB?  On the other
 
198
  hand, why not just cope?
 
199
 
 
200
* Perhaps allow people to specify a revision-id, much as people have
 
201
  unique but human-assigned names for patches at the moment?
 
202
 
 
203
----
 
204
 
 
205
20050218090900.GA2071@opteron.random
 
206
 
 
207
    Subject:      Re: [darcs-users] Re: [BK] upgrade will be needed
 
208
    From:         Andrea Arcangeli <andrea@suse.de>
 
209
    Newsgroups:   gmane.linux.kernel
 
210
    Date:         Fri, 18 Feb 2005 10:09:00 +0100
 
211
 
 
212
    On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote:
 
213
    > small to medium sized ones). Last I checked, Arch was still too slow in 
 
214
    > some areas, though that might have changed in recent months. Also, many 
 
215
 
 
216
    IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the
 
217
    backend and a single file for the changesets and with sane parameters
 
218
    conventions miming SVN. The internal algorithms of arch seems the most
 
219
    advanced possible. It's just the interface and the fs backend that's so
 
220
    bad and doesn't compress in the backups either.  SVN bsddb doesn't
 
221
    compress either by default, but at least the new fsfs compresses pretty
 
222
    well, not as good as CVS, but not as badly as bsddb and arch either.
 
223
 
 
224
    I may be completely wrong, so take the above just as a humble
 
225
    suggestion.
 
226
 
 
227
    darcs scares me a bit because it's in haskell, I don't believe very much
 
228
    in functional languages for compute intensive stuff, ram utilization
 
229
    skyrockets sometime (I wouldn't like to need >1G of ram to manage the
 
230
    tree). Other languages like python or perl are much slower than C/C++
 
231
    too but at least ram utilization can be normally dominated to sane
 
232
    levels with them and they can be greatly optimized easily with C/C++
 
233
    extensions of the performance critical parts.
 
234
 
 
235
 
 
236
-----
 
237
 
 
238
When sending patches by email (optionall) send each one as a separate
 
239
mail, with a sequence number [%03d/%03d] at the start of the Subject.
 
240
See mail from linus 2005-04-07.
 
241
 
 
242
http://linux.yyz.us/patch-format.html
 
243
 
 
244
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
 
245
 
 
246
----
 
247
 
 
248
dwmw2 (2005-04-07) 
 
249
 
 
250
reorder patches by cherry-picking them from a main development tree
 
251
before sending them on.
 
252
 
 
253
----
 
254
 
 
255
ignore BitKeeper
 
256
 
 
257
re-add should give the same id as before