Re: [changeset] don't remove whitespace within @example in docstrings

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

John W. Eaton
Administrator
On  6-Jan-2009, Jaroslav Hajek wrote:

| qrefresh supports -e, which launches an editor for the message. import
| does not support -e, but I guess I could add it easily.

If you are just importing a change, why would you change the log
message?  Would that be needed often?  You can always qimport a
change, then edit it, then qrefresh and qfinish.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Jaroslav Hajek-2
On Tue, Jan 6, 2009 at 2:50 PM, John W. Eaton <[hidden email]> wrote:
> On  6-Jan-2009, Jaroslav Hajek wrote:
>
> | qrefresh supports -e, which launches an editor for the message. import
> | does not support -e, but I guess I could add it easily.
>
> If you are just importing a change, why would you change the log
> message?  Would that be needed often?  You can always qimport a
> change, then edit it, then qrefresh and qfinish.
>

Sorry, I meant commit, not import.

> jwe
>



--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

John W. Eaton
Administrator
On  6-Jan-2009, Jaroslav Hajek wrote:

| On Tue, Jan 6, 2009 at 2:50 PM, John W. Eaton <[hidden email]> wrote:
| > On  6-Jan-2009, Jaroslav Hajek wrote:
| >
| > | qrefresh supports -e, which launches an editor for the message. import
| > | does not support -e, but I guess I could add it easily.
| >
| > If you are just importing a change, why would you change the log
| > message?  Would that be needed often?  You can always qimport a
| > change, then edit it, then qrefresh and qfinish.
| >
|
| Sorry, I meant commit, not import.

Doesn't commit open an editor to edit the log entry by default?

Also, for importing, if you need to edit the log entry, I think you
can just edit the changeset file before importing.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Jaroslav Hajek-2
On Tue, Jan 6, 2009 at 2:57 PM, John W. Eaton <[hidden email]> wrote:

> On  6-Jan-2009, Jaroslav Hajek wrote:
>
> | On Tue, Jan 6, 2009 at 2:50 PM, John W. Eaton <[hidden email]> wrote:
> | > On  6-Jan-2009, Jaroslav Hajek wrote:
> | >
> | > | qrefresh supports -e, which launches an editor for the message. import
> | > | does not support -e, but I guess I could add it easily.
> | >
> | > If you are just importing a change, why would you change the log
> | > message?  Would that be needed often?  You can always qimport a
> | > change, then edit it, then qrefresh and qfinish.
> | >
> |
> | Sorry, I meant commit, not import.
>
> Doesn't commit open an editor to edit the log entry by default?
>

Apparently, it does. Sorry for the noise.


> Also, for importing, if you need to edit the log entry, I think you
> can just edit the changeset file before importing.
>
> jwe
>



--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Thomas Weber-8
In reply to this post by John W. Eaton
Am Dienstag, den 06.01.2009, 08:47 -0500 schrieb John W. Eaton:
> On  6-Jan-2009, John W. Eaton wrote:
>
> | The disadvantages I see are that this amount of information can't
>
> One other potential problem is that although currently we can fix up
> ChangeLog entries if they are incomplete or in error, I don't think
> there is any way to do that with the Mercurial log messages.  Or am I
> missing something?

It is possible, but may result in a lot of problems:
http://www.selenic.com/mercurial/wiki/index.cgi/EditingHistory

Essentially, from the very first change onwards, the hashes change. So
people would have to rebase their repositories.

I guess that doing this like once every X months would be possible.

        Thomas

Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Jaroslav Hajek-2
On Tue, Jan 6, 2009 at 3:35 PM, Thomas Weber
<[hidden email]> wrote:

> Am Dienstag, den 06.01.2009, 08:47 -0500 schrieb John W. Eaton:
>> On  6-Jan-2009, John W. Eaton wrote:
>>
>> | The disadvantages I see are that this amount of information can't
>>
>> One other potential problem is that although currently we can fix up
>> ChangeLog entries if they are incomplete or in error, I don't think
>> there is any way to do that with the Mercurial log messages.  Or am I
>> missing something?
>
> It is possible, but may result in a lot of problems:
> http://www.selenic.com/mercurial/wiki/index.cgi/EditingHistory
>
> Essentially, from the very first change onwards, the hashes change. So
> people would have to rebase their repositories.
>
> I guess that doing this like once every X months would be possible.
>

Normal members of the Octave group can't work with the repo directly,
our access is limited to comitting. Perhaps John can?


>        Thomas
>
>



--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

John W. Eaton
Administrator
On  6-Jan-2009, Jaroslav Hajek wrote:

| Normal members of the Octave group can't work with the repo directly,
| our access is limited to comitting. Perhaps John can?

I don't think I can delete or replace the archive on savannah.  As far
as I know, we would need to ask for assistance from the savannah
admins to do that.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Thomas Weber-8
Am Dienstag, den 06.01.2009, 09:55 -0500 schrieb John W. Eaton:
> On  6-Jan-2009, Jaroslav Hajek wrote:
>
> | Normal members of the Octave group can't work with the repo directly,
> | our access is limited to comitting. Perhaps John can?
>
> I don't think I can delete or replace the archive on savannah.  As far
> as I know, we would need to ask for assistance from the savannah
> admins to do that.

Okay, different proposal: how about we split the changelogs after a new
release?

That is, we don't keep a current changelog but generate it at "make
dist" time, say "ChangeLog-3.1.52". That is then added to the repository
(or appended to the normal ChangeLog). Spelling or errors could then be
corrected (as separate Changesets), but we wouldn't touch that file for
normal changes.

Essentially, the Changelog would become some sort of NEWS file, but with
a different focus.

        Thomas

Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

John W. Eaton
Administrator
On  6-Jan-2009, Thomas Weber wrote:

| Okay, different proposal: how about we split the changelogs after a new
| release?
|
| That is, we don't keep a current changelog but generate it at "make
| dist" time, say "ChangeLog-3.1.52". That is then added to the repository
| (or appended to the normal ChangeLog).

If we generate ChangeLog files automatically, I wasn't planning to try
to keep them in the Mercuial archive at all.  Or, as you suggest, we
could split them periodically if there is some need to do that (say
the generated file is large, and it would be useful to start fresh).
But generating a new file at each snapshot or seems too often to me

| Spelling or errors could then be
| corrected (as separate Changesets), but we wouldn't touch that file for
| normal changes.

In the mean time, where would that information be stored?  Fixing
spelling errors would be fairly easy, but I supect we would not
remember to fix more serious problems like missing information.
Probably it doesn't really matter too much anyway.  It's just the
ChangeLog...

Also, I think it is important for the "make dist" target to do everything
automatically.  Hand-editing files for a release is just plain
inconvenient (and probably unreliable).

Maybe others feel differently about it, but I'd rather not be doing

  make dist
  untar
  edit
  tar
  compress

or even to have to remember to do

  make ChangeLog
  edit
  make dist

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Daniel Sebald
John W. Eaton wrote:

> On  6-Jan-2009, Thomas Weber wrote:
>
> | Okay, different proposal: how about we split the changelogs after a new
> | release?
> |
> | That is, we don't keep a current changelog but generate it at "make
> | dist" time, say "ChangeLog-3.1.52". That is then added to the repository
> | (or appended to the normal ChangeLog).
>
> If we generate ChangeLog files automatically, I wasn't planning to try
> to keep them in the Mercuial archive at all.  Or, as you suggest, we
> could split them periodically if there is some need to do that (say
> the generated file is large, and it would be useful to start fresh).
> But generating a new file at each snapshot or seems too often to me
>
> | Spelling or errors could then be
> | corrected (as separate Changesets), but we wouldn't touch that file for
> | normal changes.
>
> In the mean time, where would that information be stored?  Fixing
> spelling errors would be fairly easy, but I supect we would not
> remember to fix more serious problems like missing information.
> Probably it doesn't really matter too much anyway.  It's just the
> ChangeLog...
>
> Also, I think it is important for the "make dist" target to do everything
> automatically.  Hand-editing files for a release is just plain
> inconvenient (and probably unreliable).


Yes, definitely.  That is getting too far afield.  That edit might not be difficult, but the problem is making a release and having forgotten it; very messy.

What would be nice is a variant of

   hg log -style ChangeLog

that creates a single entry at the time of check in.  Then have a script append that short file to the top of the ChangeLog file.  Exclude the ChangeLog from checkin; then check it in as part of the "build-release script" in order to avoid a recursive or double check-in sort of thing, e.g., check in changes, then check in change to ChangeLog (that'd be silly)...  Or, simply have the change to ChangeLog be checked in on the following change and developers can go to the HTML interface to view the most recent version of ChangeLog (might be confusing).

Dan
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

John W. Eaton
Administrator
On  6-Jan-2009, Daniel J Sebald wrote:

| that creates a single entry at the time of check in.  Then have a
| script append that short file to the top of the ChangeLog file.
| Exclude the ChangeLog from checkin; then check it in as part of the
| "build-release script" in order to avoid a recursive or double

I think that if we auto-generate the ChangeLogs for distribution
files, then, like other auto-generated files, the ChangeLogs should
not be checked in to the version control system.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Daniel Sebald
John W. Eaton wrote:

> On  6-Jan-2009, Daniel J Sebald wrote:
>
> | that creates a single entry at the time of check in.  Then have a
> | script append that short file to the top of the ChangeLog file.
> | Exclude the ChangeLog from checkin; then check it in as part of the
> | "build-release script" in order to avoid a recursive or double
>
> I think that if we auto-generate the ChangeLogs for distribution
> files, then, like other auto-generated files, the ChangeLogs should
> not be checked in to the version control system.

The ChangeLog could be editted that way though.  Mercurial wouldn't be regenerating the whole file, just adding to it one entry at a time.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Daniel Sebald
In reply to this post by Jaroslav Hajek-2
Jaroslav Hajek wrote:

> On Mon, Jan 5, 2009 at 5:32 PM, John W. Eaton <[hidden email]> wrote:
>
>>On  5-Jan-2009, Jaroslav Hajek wrote:
>>
>>| Applied.
>>
>>Thanks for applying this change.
>>
>>It still seems confusing to me that you leave the ChangeLog entry
>>alone when applying patches.  If I do "hg log" now, I see
>>
>> changeset:   8444:c3ac9f2772cd
>> tag:         tip
>> user:        Thorsten Meyer <[hidden email]>
>> date:        Mon Jan 05 10:54:22 2009 +0100
>> summary:     do not eat white space within @example environments of docstrings

So this is how to get the date of some change to use in the "revert" routine to get a specific version?  E.g.,

hg revert -dMon Jan 05 10:54:22 2009 +0100 <URL>

Looking at the web interface I see an "hours ago" or "minutes" ago.  That's good for relative time, but it doesn't exactly indicate the time the change was made because "hours ago" doesn't factor in time zone.  One can follow the link to details about the change set, but the date there doesn't reflect the time checked in--if I'm following correctly.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Thorsten Meyer
In reply to this post by Jaroslav Hajek-2
Jaroslav Hajek wrote:

> On Tue, Jan 6, 2009 at 1:45 PM, John W. Eaton <[hidden email]> wrote:
>> On  6-Jan-2009, Jaroslav Hajek wrote:
>>
>> | Now that's an idea I really don't like (because of the amount of
>> | manual editing it brings).
>> | In that case, I'd vote for getting rid of ChangeLog files.
>>
>> Yes, I know it is extra work (I've done a lot of it).  But it is
>> easier than always inserting the ChangeLog entires separately (i.e.,
>> if they are not included in the diffs).
>>
>> | Using my approach, the entries bear their date of origin, but are
>> | sorted in the order they were applied, which I always found enough for
>> | all practical matters.
>>
>> To me, that is just confusing because it looks like the entries are
>> sorted incorrectly.
>>
>> | Sure; but what to do with the existing ChangeLog files? Can they be
>> | imported somehow into Mercurial? Can Savannah handle this? If we just
>> | leave them, the result will be sort of messy, won't it?
>>
>> We keep the old ChangeLog files with names like ChangeLog.1, same as
>> we always have.
>>
>> The information in the generated ChangeLog files is only from after
>> the time of the switch.
>>
>
> OK, I'm fine with this solution. So, shall we do it now?
>
>
I also like this solution. Yet I am still a little confused about what it means in detail. Let me
try a little recap. The proposal seems to be this:
 - We no longer write ChangeLog entries
 - Instead write commit messages like in John's example:

    one line summary

    * file1.cc (function): What changed.
    (other_function): Other change.
    * file2.cc (function): Another change.

 - The old ChangeLog files are renamed to ChangeLog.number
 - ChangeLog files are generated using
     hg log --style=changelog
   with releases of octave.

I have a few questions:
 - how to we credit contributions of people who do not push to savannah themselves in the future?
   I think we should add the name of the contributor to the commit message (unless
   contributor=committing person).
 - Should we also add the creation date of the patch?
 - What should be the format of the commit
   message then?
 - Will there be some correspondence between the names of the NEWS files and the names of the
corresponding (autogenerated) ChangeLog files?
 - Or will there be only one big ChangeLog file containing everything changed from now on?


regards

Thorsten
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

John W. Eaton
Administrator
On 18-Jan-2009, Thorsten Meyer wrote:

| I also like this solution. Yet I am still a little confused about what it means in detail. Let me
| try a little recap. The proposal seems to be this:
|  - We no longer write ChangeLog entries
|  - Instead write commit messages like in John's example:
|
|     one line summary
|
|     * file1.cc (function): What changed.
|     (other_function): Other change.
|     * file2.cc (function): Another change.
|
|  - The old ChangeLog files are renamed to ChangeLog.number
|  - ChangeLog files are generated using
|      hg log --style=changelog
|    with releases of octave.
|
| I have a few questions:
|  - how to we credit contributions of people who do not push to savannah themselves in the future?

When you create the changeset, you can use the

  --user "user name <email@address>"

option to commit, qnew, or qrefresh.  That way the specified user name
shows up in the commit log instead of your ID.  I also recomment using
the --currentdate option to qnew or qrefresh so the timestamp on the
patch is updated each time you refresh a patch in the MQ.  I have this
as a default in my .hgrc file:

  [defaults]
  qnew = --currentdate --currentuser
  qrefresh = --currentdate

|    I think we should add the name of the contributor to the commit message (unless
|    contributor=committing person).

I think all that needs to be done is for you to use the --user option
when commiting a change.

|  - Should we also add the creation date of the patch?

I don't see that this date is important.

|  - Will there be some correspondence between the names of the NEWS files and the names of the
| corresponding (autogenerated) ChangeLog files?

The NEWS file should be created by hand.  It should list user-visible
changes.  Ideally, each changeset should include

  a patch for the sources that meets the coding conventions

  a commit log entry in the format above

  a NEWS file entry if there is a user-visible change

  an update to the user manual if there is a user-visible change

I know that I've been quite negligent when it comes to updating the
NEWS file and user manual, and currently we don't require contributors
to have all these things done before accepting a patch (mostly for
fear of making the barrier to contributing too high).  Plus, until now
we've not really had much of a guide for contributors.  So I've tended
to fix up formatting issues and write ChangeLog entries myself.  But
as the number of contributors increases, we may want to be more strict
in the requirements, so that contributors are doing some of this work
instead of us.  But we'll have to make a case for why these rules
matter, as my sense is that many contributors don't see the point.
But I certainly think it is important for the sources to have a
consistent appearance as it makes them easier to read.

|  - Or will there be only one big ChangeLog file containing everything changed from now on?

Yes, there will only be one ChangeLog file at the top level in the tar
file distributions.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Daniel Sebald
I've back-tracked through the Maintainers dicussion list about choosing a new version-control-system, Mercurial or Git, of last year to get up to speed on things.  (I missed first time around.)  I've also investigated some of the recent distributed VCSs.  I have some general comments and then replies to John specific points below regarding ChangeLogs.

First, general comments:

I see the advantages of distributed VCS and atomic changesets.  CVS always did feel sort of klunky leaving me a bit exhausted trying to organize things.  The top three DVCSs (bzr, hg, git) all work easily enough.

Bazaar does not restore deleted files when doing 'uncommit'.  Must do an extra command for that.  Mercurial does restore the deleted files of a 'rollback'.  I prefer that.

All three DVCSs will 'rollback', 'uncommit', 'revert' a changeset, but in all cases the files don't have the same date as when they were commited.  I wish the date was retained.  Perhaps that doesn't make sense in the DVCS paradigm, but for convenience when working with the local copy only that would be nice.  Having the files touched as a result of rolling back might cause recompiling.  Plus dates of files contain
information that keeps my mind organized when coding.

As for Mercurial, one rollback is kind of limiting.  Being able to edit comments
(i.e., "recommit") *as far back as the last clone/push/pull* would be very
convenient.  So many times I've looked back at a comment and wanted to correct
or better state something.  Note that I said as far back as the last
clone/push/pull.  Once a changeset is propogated, modifying comments isn't good
practice.  So long as it is a local copy, however, greater flexibility would be
nice.  (With that in mind, even one allowed "rollback" is too much if something
has been pushed/pulled/cloned.)

Git seems to have a more robust method of branching and maintaining old changesets
compared to others.  It is sort of the way I'd imagine a branch working.  (Hard to
program, too, I imagine.)

Mercurial's advantage is syntax cleanliness and intuitiveness; same for automating
things enough, but not too much.  And that may be enough in and of itself.

Case in point.  I've tried some Git examples.  According to documentation, one has
to add the file to a staging area for every change.  My thought is, "I added this
file already, why must I do it again?"  I'm perplexed, with all the Git users
complaints about CVS, why build a system that essentially requires the same amount
of effort to place every file into a staging area first?  Yes, there is the '-a'
option.  But that is sort of an extraneous thing if 95% of the time it is used.
A '-a' is a long pinky stretch on the keyboard, and consequently has higher
likelihood of error... requiring a long hand movement to 'backspace'.

Git 'diff' will display an empty file when there are no changes.  Mercurial just
returns to the command line.  Again, Hg just seems to be more efficient in terms
of keystrokes.

Now, allow me to address some of John's comments.


John W. Eaton wrote:

> On 18-Jan-2009, Thorsten Meyer wrote:
>
> | I also like this solution. Yet I am still a little confused about
> what it means in detail. Let me | try a little recap. The proposal
> seems to be this: |  - We no longer write ChangeLog entries |  -
> Instead write commit messages like in John's example: | |     one
> line summary | |     * file1.cc (function): What changed. |
> (other_function): Other change. |     * file2.cc (function): Another
> change. | |  - The old ChangeLog files are renamed to
> ChangeLog.number |  - ChangeLog files are generated using |      hg
> log --style=changelog |    with releases of octave. | | I have a few
> questions: |  - how to we credit contributions of people who do not
> push to savannah themselves in the future?
>
> When you create the changeset, you can use the
>
> --user "user name <email@address>"

Save some effort, define this in the .hgrc file.


> option to commit, qnew, or qrefresh.  That way the specified user
> name shows up in the commit log instead of your ID.  I also recomment
> using the --currentdate option to qnew or qrefresh so the timestamp
> on the patch is updated each time you refresh a patch in the MQ.  I
> have this as a default in my .hgrc file:
>
> [defaults] qnew = --currentdate --currentuser qrefresh =
> --currentdate
>
> |    I think we should add the name of the contributor to the commit
> message (unless |    contributor=committing person).
>
> I think all that needs to be done is for you to use the --user option
>  when commiting a change.
>
> |  - Should we also add the creation date of the patch?
>
> I don't see that this date is important.

There was debate about the date to use:  Time of changeset creation?  Or time
of push into canonical repository?  I'd prefer the latter and notice I used
the word canonical.  I can see the logic of changeset creation date having
more meaning in a DVCS where atomic changesets can be moved about.  But John
has set up a canonical repository where I think ChangeLog has meaning (and I
would miss I think).  The ChangeLog should have the date when the changeset
was moved into the canonical repository.

Here is what I think would be the best solution, and if it isn't a Mercurial
feature it might be worthwhile for one of us to make a feature request to the developers.

One should be able to build a "template comment file", say .hgtemplate or
something.  The default format is not something like:

----

HG: Enter commit message.  Lines beginning with 'HG:' are removed.
HG: --
HG: user: [hidden email]
HG: branch 'default'
HG: changed junk.txt
HG: changed junk2.txt


Why not allow the user to define a template with a few simple codes that
will pop up a commit message like:

----
First line is displayed in 'hg log'.

2008-02-06  Daniel J. Sebald  <[hidden email]>

        * junk.txt:
        * junk2.txt:
HG: Enter commit message.  Lines beginning with 'HG:' are removed.
HG: --
HG: user: [hidden email]
HG: branch 'default'
HG: changed junk.txt

Just fill in the missing comments and it is formatted with a consistent
ChangeLog entry (the date is current date, no tab/space inconsistency)
that could be sorted with some Hg plugin.  Perhaps Hg would shreek at such
an idea.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

John W. Eaton
Administrator
On  7-Feb-2009, Daniel J Sebald wrote:

| As for Mercurial, one rollback is kind of limiting.  Being able to
| edit comments (i.e., "recommit") *as far back as the last
| clone/push/pull* would be very convenient.  So many times I've
| looked back at a comment and wanted to correct or better state
| something.  Note that I said as far back as the last
| clone/push/pull.  Once a changeset is propogated, modifying comments
| isn't good practice.  So long as it is a local copy, however,
| greater flexibility would be nice.  (With that in mind, even one
| allowed "rollback" is too much if something has been
| pushed/pulled/cloned.)

Use Mercurial queues if you want to be able to edit your local
changesets before committing them.

| Now, allow me to address some of John's comments.
|
|
| John W. Eaton wrote:
| > On 18-Jan-2009, Thorsten Meyer wrote:
| >
| > When you create the changeset, you can use the
| >
| > --user "user name <email@address>"
|
| Save some effort, define this in the .hgrc file.

I'm not sure now, but the point might have been that if you are
incorporating changes from someone else, you can attribute the change
to them by using the --user option.  Of course everyone should put the
default user ID they prefer to use in their .hgrc file.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Daniel Sebald
John W. Eaton wrote:

> On  7-Feb-2009, Daniel J Sebald wrote:
>
> | As for Mercurial, one rollback is kind of limiting.  Being able to
> | edit comments (i.e., "recommit") *as far back as the last
> | clone/push/pull* would be very convenient.  So many times I've
> | looked back at a comment and wanted to correct or better state
> | something.  Note that I said as far back as the last
> | clone/push/pull.  Once a changeset is propogated, modifying comments
> | isn't good practice.  So long as it is a local copy, however,
> | greater flexibility would be nice.  (With that in mind, even one
> | allowed "rollback" is too much if something has been
> | pushed/pulled/cloned.)
>
> Use Mercurial queues if you want to be able to edit your local
> changesets before committing them.

Oh, I'll look that up...  Thanks!


> | Now, allow me to address some of John's comments.
> |
> |
> | John W. Eaton wrote:
> | > On 18-Jan-2009, Thorsten Meyer wrote:
> | >
> | > When you create the changeset, you can use the
> | >
> | > --user "user name <email@address>"
> |
> | Save some effort, define this in the .hgrc file.
>
> I'm not sure now, but the point might have been that if you are
> incorporating changes from someone else, you can attribute the change
> to them by using the --user option.  Of course everyone should put the
> default user ID they prefer to use in their .hgrc file.

Oh, yeah.  I see now what you meant.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Thorsten Meyer
In reply to this post by John W. Eaton
John W. Eaton wrote:

> On 18-Jan-2009, Thorsten Meyer wrote:
>
> | I also like this solution. Yet I am still a little confused about what it means in detail. Let me
> | try a little recap. The proposal seems to be this:
> |  - We no longer write ChangeLog entries
> |  - Instead write commit messages like in John's example:
> |
> |     one line summary
> |
> |     * file1.cc (function): What changed.
> |     (other_function): Other change.
> |     * file2.cc (function): Another change.
> |
> |  - The old ChangeLog files are renamed to ChangeLog.number
> |  - ChangeLog files are generated using
> |      hg log --style=changelog
> |    with releases of octave.
> |
> | I have a few questions:
> |  - how to we credit contributions of people who do not push to savannah themselves in the future?
>
> When you create the changeset, you can use the
>
>   --user "user name <email@address>"
>
> option to commit, qnew, or qrefresh.  That way the specified user name
> shows up in the commit log instead of your ID.  I also recomment using
> the --currentdate option to qnew or qrefresh so the timestamp on the
> patch is updated each time you refresh a patch in the MQ.  I have this
> as a default in my .hgrc file:
>
>   [defaults]
>   qnew = --currentdate --currentuser
>   qrefresh = --currentdate
>
> |    I think we should add the name of the contributor to the commit message (unless
> |    contributor=committing person).
>
> I think all that needs to be done is for you to use the --user option
> when commiting a change.
>
> |  - Should we also add the creation date of the patch?
>
> I don't see that this date is important.
>
> |  - Will there be some correspondence between the names of the NEWS files and the names of the
> | corresponding (autogenerated) ChangeLog files?
>
> The NEWS file should be created by hand.  It should list user-visible
> changes.  Ideally, each changeset should include
>
>   a patch for the sources that meets the coding conventions
>
>   a commit log entry in the format above
>
>   a NEWS file entry if there is a user-visible change
>
>   an update to the user manual if there is a user-visible change
>
> I know that I've been quite negligent when it comes to updating the
> NEWS file and user manual, and currently we don't require contributors
> to have all these things done before accepting a patch (mostly for
> fear of making the barrier to contributing too high).  Plus, until now
> we've not really had much of a guide for contributors.  So I've tended
> to fix up formatting issues and write ChangeLog entries myself.  But
> as the number of contributors increases, we may want to be more strict
> in the requirements, so that contributors are doing some of this work
> instead of us.  But we'll have to make a case for why these rules
> matter, as my sense is that many contributors don't see the point.
> But I certainly think it is important for the sources to have a
> consistent appearance as it makes them easier to read.
>
> |  - Or will there be only one big ChangeLog file containing everything changed from now on?
>
> Yes, there will only be one ChangeLog file at the top level in the tar
> file distributions.
>
What happened to the plan (or was it a plan already?) to move the ChangeLog
entries into the mercurial commit messages?

regards

Thorsten
Reply | Threaded
Open this post in threaded view
|

Re: ChangeLogs

Rik-5
In reply to this post by Daniel Sebald

>>
> What happened to the plan (or was it a plan already?) to move the ChangeLog
> entries into the mercurial commit messages?
This seems like a very good idea.  One of the current complications with
using a non-linear commit strategy is that everyone touches the same file,
ChangeLog, on every commit.  This leads Mercurial into attempting an
unnecessary 3-way merge of that file whenever a personal repository is
pushed back to the main repository.

--Rik
123