octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ChangeLogs (was: Re: [changeset] don't remove whitespace within @exa


From: John W. Eaton
Subject: Re: ChangeLogs (was: Re: [changeset] don't remove whitespace within @example in docstrings)
Date: Mon, 5 Jan 2009 14:37:03 -0500

On  5-Jan-2009, Thomas Weber wrote:

| On Mon, Jan 05, 2009 at 11:23:23AM -0600, Jordi GutiƩrrez Hermoso wrote:
| > 2009/1/5 John W. Eaton <address@hidden>:
| > > Or, we should simply decide to do away with ChangeLog files entirely.
| > 
| > Please don't... I like the Changelogs, since they're the only unbroken
| > breadcrumb trail we have for Octave. If in a couple of years from now
| > you decide that hg isn't doing the job anymore like CVS wasn't, then
| > we'd lose the project's history when you switch VCS.
| 
| You should have more trust in current conversion tools. I'm pretty sure
| you can switch between at least Mercurial and Git without loosing
| anything.

Yes, and I would expect that would be true of any widely used VCS
developed in the future as well.

| With distributed VCS, the importance of Changelogs has diminished. 

Yes, I agree.

| Generating changelogs with Mercurial isn't difficult, just try
|       hg log --limit 2 --style=changelog
| in Octave's directory. Adding something like this to 'make dist' hook
| wouldn't be that much work.

OK.  If we are to do this, then we should

  Only generate ChangeLog entries after the point when we stop editing
  them by hand.

  Agree on a format for the Mercurial log entries.  Future log entries
  should contain more information than they do now.

  Instead of having multiple ChangeLog files (top, doc, src,
  liboctave, libcruft, test, ...) There would only be one generated
  ChangeLog file that we would put in the tar files we distribute.

I don't see how the generated ChangeLog entries can have precisely the
format that we use now unless we edit it into the logs by hand anyway
(I'm thinking of the

        * file (function): Description.

format -- it doesn't seem that Mercurial could do that for us).  But
even without that, I'm OK with going this route once we decide on some
guidelines for the way Mercurial log entries should be written.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]