1
I think Ruby's point is right: we need to think about how a tool
2
*feels* as you're using it.
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
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
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 something other than what is shown in the editor window
18
because there are unsaved changes.
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
24
Perhaps there should be a preference to abort on unknown files, or
25
perhaps it should be possible to specify forbidden files.
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.
32
*Those who lose history are doomed to recreate it.*
33
-- broked (on #gnu.arch.users)
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!*
37
-- Tim Peters on comp.lang.python, 2001-06-16
39
(Bazaar provides mechanism and convention, but it is up to you
40
whether you wish to follow or enforce that convention.)
46
A way to subtract merges, so that you can see the work you've done
47
to a branch since conception.
53
<mpool> now that is a neat idea: advertise branches over zeroconf
54
<mpool> should make lca fun :-)
58
http://thedailywtf.com/ShowPost.aspx?PostID=24281
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.
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).
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
74
* cope without $EMAIL better
76
* notes at start of .bzr.log:
78
* or include it in bug reports
80
* should you be able to remove things from the default ignore list?
82
* headers at start of diff, giving some comments, perhaps dates
84
* is diff against /dev/null really OK? I think so.
86
* separate remove/delete commands?
88
* detect files which were removed and now in 'missing' state
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
94
without this, doing a status on a large tree can be very slow. but
95
relying on mtime/size is a bit dangerous.
97
people really do work on trees which take a large chunk of memory
98
and which will not stay in memory
100
* status up-to-date files: not 'U', and don't list without --all
102
* if status does compare file text, then it should be quick when
103
checking just a single file
105
* wrapper for svn that every time run logs
110
- sufficient to replay everything
113
* status crashes if a file is missing
115
* option for -p1 level on diff, etc. perhaps
117
* commit without message should start $EDITOR
119
* don't duplicate all files on commit
121
* start importing tridge-junkcode
123
* perhaps need xdelta storage sooner rather than later, to handle very
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.
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.
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?
143
* List difference in the revisions on one branch vs another.
145
* Perhaps use a partially-readable but still hopefully unique ID for
146
revisions/inventories?
148
* Preview what will happen in a merge before it is applied
150
* When a changeset deletes a file, should have the option to just make
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.)
160
* interactive commit, prompting whether each hunk should be sent (as
163
* Write up something about detection of unmodified files
165
* Preview a merge so as to get some idea what will happen:
167
* What revisions will be merged (log entries, etc)
169
* What files will be affected?
171
* Are those simple updates, or have they been updated locally as
174
* Any renames or metadata clashes?
176
* Show diffs or conflict markers.
178
* Do the merge, but write into a second directory.
180
* "Show me all changesets that touch this file"
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.
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.
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.
194
* Use readline for reading log messages, and store a history of
195
previous commit messages!
197
* Warn when adding huge files(?) - more than say 10MB? On the other
198
hand, why not just cope?
200
* Perhaps allow people to specify a revision-id, much as people have
201
unique but human-assigned names for patches at the moment?
205
20050218090900.GA2071@opteron.random
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
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
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.
224
I may be completely wrong, so take the above just as a humble
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.
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.
242
http://linux.yyz.us/patch-format.html
244
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
250
reorder patches by cherry-picking them from a main development tree
251
before sending them on.
257
re-add should give the same id as before
added
removed
doc/random.txt
