| 1 |
On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote: |
| 2 |
> suggestion: |
| 3 |
> stop keeping ChangeLog files in CVS and instead, let them be generated |
| 4 |
> automagically by the cvs server using the last <arbitrary number> of commit |
| 5 |
> messages. if you really want to keep a commit message out of the changelog, |
| 6 |
> then we come up with a simple policy of prefixing the message with a period |
| 7 |
> (to keep it hidden :P). |
| 8 |
|
| 9 |
This would remove the possibility of correcting an entry in the |
| 10 |
ChangeLog in case of a typo or wrong assumption etc. |
| 11 |
|
| 12 |
> logic: |
| 13 |
> - i'm lazy |
| 14 |
|
| 15 |
That's not a valid argument - you can use a bash function for calling |
| 16 |
echangelog and repoman as shown numerous times on this list. |
| 17 |
|
| 18 |
> - i hate typing the samething twice (yes, bash scripting with echangelog can |
| 19 |
> kind of take care of this) ... it doesnt handle if you want to use different |
| 20 |
> commit messages for different files |
| 21 |
|
| 22 |
Can you give an example of why you would want to use different commit |
| 23 |
messages in a single commit? |
| 24 |
|
| 25 |
> - shrinks ChangeLog size for packages which have been around a very long time |
| 26 |
|
| 27 |
This is the only real advantage I see from the above proposal - but I |
| 28 |
don't think that warrants the change. I doubt the saved space would be |
| 29 |
that significant. |
| 30 |
|
| 31 |
> - forces cvs log messages to actually be worthwhile to read and makes |
| 32 |
> browsing cvs history much nicer (it's very easy to look at the differences |
| 33 |
> between two files and match up a good commit message rather than trying to |
| 34 |
> figure out what message in the ChangeLog goes with it, assuming there is one) |
| 35 |
|
| 36 |
See my first answer (bash function). |
| 37 |
|
| 38 |
> - easily standardize ChangeLog format wrt to header, copyrights, licensing, |
| 39 |
> message formatting, name/date format |
| 40 |
|
| 41 |
Already done by echangelog. |
| 42 |
|
| 43 |
> - generate dates in UTC down to the second rather than having devs hand type |
| 44 |
> them in their local timezone for just the current day |
| 45 |
|
| 46 |
I thought echangelog already did this based on TZ? |
| 47 |
|
| 48 |
> - maybe some other things i havent thought of |
| 49 |
> - i'm lazy |
| 50 |
|
| 51 |
See my first answer (bash function). |
| 52 |
|
| 53 |
Sincerely, |
| 54 |
Brix |
| 55 |
-- |
| 56 |
Henrik Brix Andersen <brix@g.o> |
| 57 |
Gentoo Metadistribution | Mobile computing herd |
Archives