On 2/13/07, James E Keenan <[EMAIL PROTECTED]> wrote:
jerry gay wrote:
> On 2/11/07, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote:
>
>> # New Ticket Created by Paul Cochrane
>> # Please include the string: [perl #41485]
>> # in the subject line of all future correspondence about this issue.
>> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41485 >
>>
>>
> svn:eol-style should be set to 'native', so it'll save files with the
> line ending the platform expects. the only exceptions i'm aware of are
> examples using file io. as the tests are currently designed, these
> require svn:eol-style=LF (see t/examples/streams.t for more.)
>
Apropos the discussion in this thread, should any svn properties be set
on files submitted as patches or new files?
Or is this not relevant, as such files cannot yet have svn properties?
But perhaps more to the point: Suppose that I am committing new files
to a *branch* (e.g., the buildtools branch) -- files that ultimately
will be submitted to the project as patches/new files to *trunk*. What
svn properties should I set on files I'm committing to my branch?
(So far, I'm just adding 'svn:keywords "Id"', because otherwise I don't
get proper updates in my svn Id tags.)
the metadata requirements for parrot repo files are poorly documented.
there's a little info in docs/submissions.pod, and a little at
http://www.parrotcode.org/source.html. if you count tests as
documentation (i do,) then t/distro/file_metadata.t is another place
to look.
the documentation for file metadata is not well organized, nor
complete. i'm not certain where this info best fits, but the coding
standard pdd seems like a good candidate. in any case, the general
rule (there are exceptions) is that the following properties have the
following settings on the listed filetypes:
[*.*]: svn:eol-style=native
[*.*]: svn:keywords="Author Date Id Revision"
[*.t]: svn:mime-type=text/plain
and hopefully someday svn will support custom keywords (it's been
threatened for years) and we can add "Year" and/or "Copyright" -- but
that's another story.
the cleanup and organization of documentation related to svn
properties should be tracked in a separate ticket.
~jerry
