> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 10:46 PM
> To: [EMAIL PROTECTED]
> Subject: Process for checking in files and resolving bugs
>
>
> Outside of adding a reasonable checkin comment, is there some
> other process or
> information that is needed when I'm checking in files?
Not really, unless you're fixing a bug, in which case it's good to list the
bug number, and attribute the reporter (and patch submitter, if applicable).
When adding new features, it's not a bad idea to include enough information
in the commit message so that other people know how to use it (and therefore
document it).
>
> I noticed that when I try to use the internal "cvs" interface
> in XEmacs, I'm
> unable to complete the commit process (gnuclient's connection
> gets "reset by
> peer"), although this might be some problem with XEmacs
> and/or gnuserv. I have
> no problem checking files out with this interface. When I do
> try to submit
> using this interface, the buffer gets filled in with some
> comments, like saying
> that I should fill in a "PR" number, which I would guess is
> the bugzilla
> problem report number. When I do this submit in WinCVS (as I
> can't get it done
> with XEmacs), the checkin comments buffer doesn't show that
> information. I'm
> not certain exactly what initializes that buffer.
The text you're seeing comes from a CVS template file. You'll find it in
jakarta-struts/CVS/Template. I don't know if WinCVS looks for a template
file at all, but if it does, most likely it's looking only in the directory
from which you're checking in. Since only the top level directory has the
template file, WinCVS won't pick it up. For this reason, although I use
WinCVS for updates and diffs, I always use command-line CVS from the top
level (i.e. from my jakarta-struts directory) for commits.
BTW, another reason to avoid WinCVS for commits is that the comment dialog
gives no indication of line length, and lines don't get broken. This isn't
so much of a problem with the way we use keywords at Jakarta, but if you
ever use the Log keyword in source files, you end up with checkin comments
that are one very long line, which is pretty annoying.
I can't help with the XEmacs problem, not being an emacs user myself.
>
> With respect to any bug number that I'm submitting code
> against, what is a
> reasonable process for verifying the bug is "fixed" so I can
> resolve it? I can
> easily test it in my distribution, but do I have to install
> and test it in the
> next nightly build, or what?
I just test as much as I can in my own build, after using 'ant clean dist'
to make sure I'm building everything properly. If it's a tag bug, I'll take
it for a spin with the exercise-taglib; if it's something used in an
example, I'll test it that way; and if it's something I use in my own
applications, I'll often test that too.
--
Martin Cooper
>
> --
> ===================================================================
> David M. Karr ; Java/J2EE/XML/Unix/C++
> [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
