You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/10/16 06:33:20 UTC

relative pathnames in ChangeLogs

After I generated/updated the latest ChangeLogs I noticed that we have
been less than completely consistent in how we refer to changed files
in Change Log entries. Most of the time, although not all of the time,
we just mention the file name w/o the directory prefix. That's not a
big deal when all the files in the ChangeLog entry reside in the same
directory (although even then it's less than ideal), but it becomes
a potential problem when there are files from different directories,
e.g., include/foo.h and src/bar.h, because there may be a src/foo.h
in addition to include/foo.h.

To avoid this potential problem I would like to propose that each file
mentioned in a Change Log entry be relative to the directory containing
the ChangeLog itself. I.e., file names referenced in the ChangeLog
residing under trunk/include/ will be relative to trunk/include/, those
reference in the ChangeLog residing under trunk/tests will be relative
to trunk/tests, and so on.

For example, the ChangeLog entry for the following change:
   http://svn.apache.org/viewvc?view=rev&revision=583398
would look like so:

2007-10-10 Travis Vitek <vi...@roguewave.com>

	STDCXX-582
	* self/0.printf.cpp (test_errno): Deallocate memory allocated
	automatically by rw_snprintfa().

Change Log entries that refer to files from multiple subdirectories
(e.g., trunk/include and trunk/examples) would have to also include
the name of the subdirectories.

Does this sound reasonable to everyone? Does anyone have a better idea?

Martin

RE: relative pathnames in ChangeLogs

Posted by Travis Vitek <tv...@roguewave.com>.
Yes.

Martin Sebor wrote:
>
>Mark Brown wrote:
>>
>> Martin,
>> 
>> This sounds reasonable to me. Although I wonder, is there any reason
>> to have a number of ChangeLogs instead of just one at the top of the
>> tree?
>
>Not really. We had src/ChangeLog (but none of the others) and it
>hadn't occurred to me that one would be sufficient when I created
>the rest, I suppose I could generate it and remove those I added
>to the subdirectories. Does that sound like the right approach
>to everyone?
>
>Martin
>

Re: relative pathnames in ChangeLogs

Posted by Martin Sebor <se...@roguewave.com>.
Mark Brown wrote:
> Martin,
> 
> This sounds reasonable to me. Although I wonder, is there any reason
> to have a number of ChangeLogs instead of just one at the top of the
> tree?

Not really. We had src/ChangeLog (but none of the others) and it
hadn't occurred to me that one would be sufficient when I created
the rest, I suppose I could generate it and remove those I added
to the subdirectories. Does that sound like the right approach
to everyone?

Martin

> 
> -- Mark
> 
> Martin Sebor wrote:
>> After I generated/updated the latest ChangeLogs I noticed that we have
>> been less than completely consistent in how we refer to changed files
>> in Change Log entries. Most of the time, although not all of the time,
>> we just mention the file name w/o the directory prefix. That's not a
>> big deal when all the files in the ChangeLog entry reside in the same
>> directory (although even then it's less than ideal), but it becomes
>> a potential problem when there are files from different directories,
>> e.g., include/foo.h and src/bar.h, because there may be a src/foo.h
>> in addition to include/foo.h.
>>
>> To avoid this potential problem I would like to propose that each file
>> mentioned in a Change Log entry be relative to the directory containing
>> the ChangeLog itself. I.e., file names referenced in the ChangeLog
>> residing under trunk/include/ will be relative to trunk/include/, those
>> reference in the ChangeLog residing under trunk/tests will be relative
>> to trunk/tests, and so on.
>>
>> For example, the ChangeLog entry for the following change:
>>   http://svn.apache.org/viewvc?view=rev&revision=583398
>> would look like so:
>>
>> 2007-10-10 Travis Vitek <vi...@roguewave.com>
>>
>>     STDCXX-582
>>     * self/0.printf.cpp (test_errno): Deallocate memory allocated
>>     automatically by rw_snprintfa().
>>
>> Change Log entries that refer to files from multiple subdirectories
>> (e.g., trunk/include and trunk/examples) would have to also include
>> the name of the subdirectories.
>>
>> Does this sound reasonable to everyone? Does anyone have a better idea?
>>
>> Martin
>>
> 


Re: relative pathnames in ChangeLogs

Posted by Mark Brown <ma...@gmail.com>.
Martin,

This sounds reasonable to me. Although I wonder, is there any reason
to have a number of ChangeLogs instead of just one at the top of the
tree?

-- Mark

Martin Sebor wrote:
> After I generated/updated the latest ChangeLogs I noticed that we have
> been less than completely consistent in how we refer to changed files
> in Change Log entries. Most of the time, although not all of the time,
> we just mention the file name w/o the directory prefix. That's not a
> big deal when all the files in the ChangeLog entry reside in the same
> directory (although even then it's less than ideal), but it becomes
> a potential problem when there are files from different directories,
> e.g., include/foo.h and src/bar.h, because there may be a src/foo.h
> in addition to include/foo.h.
> 
> To avoid this potential problem I would like to propose that each file
> mentioned in a Change Log entry be relative to the directory containing
> the ChangeLog itself. I.e., file names referenced in the ChangeLog
> residing under trunk/include/ will be relative to trunk/include/, those
> reference in the ChangeLog residing under trunk/tests will be relative
> to trunk/tests, and so on.
> 
> For example, the ChangeLog entry for the following change:
>   http://svn.apache.org/viewvc?view=rev&revision=583398
> would look like so:
> 
> 2007-10-10 Travis Vitek <vi...@roguewave.com>
> 
>     STDCXX-582
>     * self/0.printf.cpp (test_errno): Deallocate memory allocated
>     automatically by rw_snprintfa().
> 
> Change Log entries that refer to files from multiple subdirectories
> (e.g., trunk/include and trunk/examples) would have to also include
> the name of the subdirectories.
> 
> Does this sound reasonable to everyone? Does anyone have a better idea?
> 
> Martin
>