Le Fri, Feb 15, 2002, à 03:55:16AM -0800, Matts Kivik a écrit:
I have moved the connection point of the micrphone symbol. I have also added a control point to the speaker symbol. I suggest that the changes is added to cvs/dist.
I'm applying this. However, this is the last time I ever accept a set of
changed files in Windows Zip format (as opposed to a gzipped unidiff
relative to the CVS head, with all sheet changes done in the .sheet.in files
rather than the compiled & localised .sheet files), and without a suitable
ChangeLog entry.
OK, for the sake of having an URL in the archives to point future people to,
I'll recap how are the customs (this usually applies for most other
projects), give or take some project-specific details; don't take this
personnally, we always are rookies one day in every new field:
The best way to generate these is to download the tree through anonymous CVS
(from cvs.gnome.org, this is possible of course also for Windows with the
"Universal Geek user interface device driver" (cygwin)).
Then, all what is necessary is to do "cvs adds" (commit will of course not
be accepted), do a "cvs -z3 up -PAd" to check that the patch will be as up
to date as possible, and issue the following command:
cvs -z3 diff -N 2>/tmp/diff.log |gzip >/tmp/some.patch.gz
Study diff.log to check that no files have been unnecessarily touched.
zless the patch to check that all changes are accounted for in the ChangeLog
and are justified (one patch per orthogonal set of changes is also
preferred).
(alternative is to have two copies, one pristine and one work area, of the
same tree, preferably a recent CVS snapshot. Modify all files and test in
the work area; then make distclean in both trees, and in the directory which
contains both trees, do something like :
diff -uRN dia-pristine dia-workarea >/tmp/some.patch
grep "^+++" /tmp/some.patch # check that no files have been unnecessarily
# touched, added or removed.
less /tmp/some.patch # check that patch is correct
gzip /tmp/some.patch
Again, this is possible even on a (okay, recent) Macintosh)
Send patch. Don't resend the same version of the patch twice on the list
(when replying to yourself with updates...). Keep large patches (> 5-40 kb)
for private mails and/or posting on a FTP or WWW site (URL in the mailing
list is of course welcome; small patches are okay, especially if some
discussion on them is sought).
For the sake of comparison, I've reformatted your contribution into the
format into which I'd have loved to receive it (of course, the one who
actually applies the patch usually gets to slightly edit the ChangeLog, but
aside from that, all he has to do is to read the patch, apply it with
patch(1), make and run (to check), commit).
-- Cyrille
--
Grumpf.
Attachment:
mkivik.patch.gz
Description: Binary data