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