On Thu, Jan 17, 2002 at 10:16:13AM +0100, Bo Thorsen wrote:
>...
> One feature that I think cvs is missing and that I don't think I've seen
> requested other places is this: Built in support for ChangeLog files. The
> most annoying part of running cvs on bigger projects (like gcc, glibc etc) is
> that ChangeLogs needs to be handled manually for each commit.
Subversion records a single log message for each commit. It actually is not
all that difficult to be able to query for *all* the log messages and
generate a file from that.
Imagine a "cvs2cl.pl" that actually works correctly. Every time.
> The problem is this: As development goes on for a new gcc patch, ChangeLog
> entries are written. Now, if the developer wants to update the tree, he has
> to remove his ChangeLog entries, do the update and reinsert them.
Assuming the ChangeLog is in the tree, yes. I can see this.
> This
> usually happens multiple times during patch development. Then, when the cvs
> diff is to be sent to the mailing list, again the ChangeLog entries has to be
> removed, since it's bad form to send ChangeLog patches. And finally when you
> commit, the entries can be put there for good.
Gotcha. Again, this is the model of "ChangeLog gets committed."
> There are basically two different ways to deal with it: Write ChangeLogs in a
> separate file and keep it there until committing or simply write the
> ChangeLog entries directly in the email when the patch is sent to the list.
> Developers usually take the second approach, resulting in less than optimal
> ChangeLogs.
The email-based ones *can* be as nice as using a separate file. It is really
a social thing, rather than a technical thing. "Are the developers willing
to pause, write a good ChangeLog, and then send the patch?" Personally, I
write the log when I commit; Karl writes the log as he works. Both of us
produce quite fine change logs.
> Right now, it's too awkward to handle ChangeLogs and it's something many
> developers waste time on. It's the obvious requirements for an automated
> solution: Manual, repetitive, boring and easily handled by an application.
> It's one of those seemingly silly problems that is surprisingly painful in
> the long run. It has annoyed me to the point where I was about to look at cvs
> sources and just do it myself.
I think the answer is to /not/ put the ChangeLog into the tree. Simply
generate it whenever you need it.
Again, Subversion record a log message on a per-commit basis. You don't have
to go and scan through 10,000 files, gather up log messages, order by date,
and then produce (what you hope is correct) a ChangeLog file. You can just
ask for it: "what are the log messages for commits 437 thru 581?"
The ChangeLog concept was created as a way to avoid the "scan the repository
for log messages and assemble a commit timeline". The burden was placed on
the user to maintain that timeline.
Not so with Subversion :-)
If the above doesn't answer your question/concern, then just ask for more
detail. If it raises *more* questions :-), then ask those.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:56 2006