Re: [dev] $Author$
Frank Schönheit - Sun Microsystems Germany wrote: Hi Heiner, A reason to drop at least the $Author$ field from the legal headers, to avoid confusion? (I wonder, anyway, why RCSs are designed and used in a way where the RCS modifies the stored content---expanding $...$ fields---, as that cannot work in general.) Yes, yes please let's do this. And while we are at it, let's remove the other $keywords$ as well. They really do make merges more complicated, without adding much of a value. In fact, with our current working style, those keywords are rather useless - unless you work in a CWS, on a file which has been altered in this CWS before, the $author$, $date$ etc. information is wrong, anyway (since it refers to the integration of the CWS where this file was previously changed). I'm in for removing it (spares me this -kk switch everytime I want to see what really happened in a file, to suppress the disturbing keyword diffs). But do we really want to touch all headers in all the files in all our modules? Whoever did the drop SISSL cleanup might know how much work such a change really is. Now, who wants to pick this up? (I'm out, I'll be on vacation for the next couple weeks :) Ideally, we would also completely disable that expansion feature in the CVS settings (whatever kind of work that means exactly), right? -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] $Author$
Hi there! Well regarding the effort to replace that line with the $Author$ this should be relativ small what you need to do is: 1.) Analyse file types and the comments contained therein and decided what you want to replace how e.g for C++ and java we need to replace a line like * last change: $Author: hr $ $Date: 2007/06/27 20:04:02 $ with a line containing just * in all .cxx, .hxx and .java files. 2.) Create a perl regular expression to do that replacement eg. for the above C++ and java case and probably likely suitable for some other cases as well that could be s/(^.*)(last change:\s*)(\$Author.*\$)(.*$)/$1$4/g 3.) find all files of those certain filetypes and combine with perl program to do the replacement. 3.1) Example for the java and C++ case (note the below is just one commandline which is wrapped to multiple lines by the mailer ) find . -name \*.hxx -o name \*.cxx -o -name *\.java | xargs perl -pi .bak -e 's/(^.*)(last change:\s*)(\$Author.*\$)(.*$)/$1$4/g'; 3.1.2) after checking that everything went well remove backup files created in the step before find . -name \*.bak | xargs rm 3.2.) If the above done in 3.1 blasts the shells commandline limit due to two much files found either use the find -e option instead of using xargs or apply per module instead of applying at once to the whole source code or similar. 4.) cvs commit your changes on a childworkspace and get that integrated Kind regards, Bernd Eilers Stephan Bergmann wrote: Frank Schönheit - Sun Microsystems Germany wrote: Hi Heiner, A reason to drop at least the $Author$ field from the legal headers, to avoid confusion? (I wonder, anyway, why RCSs are designed and used in a way where the RCS modifies the stored content---expanding $...$ fields---, as that cannot work in general.) Yes, yes please let's do this. And while we are at it, let's remove the other $keywords$ as well. They really do make merges more complicated, without adding much of a value. In fact, with our current working style, those keywords are rather useless - unless you work in a CWS, on a file which has been altered in this CWS before, the $author$, $date$ etc. information is wrong, anyway (since it refers to the integration of the CWS where this file was previously changed). I'm in for removing it (spares me this -kk switch everytime I want to see what really happened in a file, to suppress the disturbing keyword diffs). But do we really want to touch all headers in all the files in all our modules? Whoever did the drop SISSL cleanup might know how much work such a change really is. Now, who wants to pick this up? (I'm out, I'll be on vacation for the next couple weeks :) Ideally, we would also completely disable that expansion feature in the CVS settings (whatever kind of work that means exactly), right? -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] $Author$
over at [EMAIL PROTECTED], Ariel Constenla-Haile wrote: Hi Frank, Frank Schönheit - Sun Microsystems Germany escribió: Hi Ariel, FIRST of all, I would like to thank the one who wrote the code of the GUI examples on the new SDK (OpenOffice.org_2.3_SDK/examples/DevelopersGuide/GUI): it answers some questions I had for a long time! Thanks hr (I don't know your real name!)! Hehe. hr (Jens-Heiner Rechtien) is a release engineer, who integrated the child workspace where this was introduced. While he, as all our release engineers, surely deserves thanks for the work he does, in this particular case please direct your thank to Jürgen Schmidt (jsc, also to be seen in the CVS history). As I never use CVS for OOo, I just took for granted that the author of the *.java source file was the one indicated there, so here I go again: A reason to drop at least the $Author$ field from the legal headers, to avoid confusion? (I wonder, anyway, why RCSs are designed and used in a way where the RCS modifies the stored content---expanding $...$ fields---, as that cannot work in general.) But don't take this too seriously... :) -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] $Author$
Hi Stephan, Stephan Bergmann escribió: over at [EMAIL PROTECTED], Ariel Constenla-Haile wrote: Hi Frank, Frank Schönheit - Sun Microsystems Germany escribió: Hi Ariel, FIRST of all, I would like to thank the one who wrote the code of the GUI examples on the new SDK (OpenOffice.org_2.3_SDK/examples/DevelopersGuide/GUI): it answers some questions I had for a long time! Thanks hr (I don't know your real name!)! Hehe. hr (Jens-Heiner Rechtien) is a release engineer, who integrated the child workspace where this was introduced. While he, as all our release engineers, surely deserves thanks for the work he does, in this particular case please direct your thank to Jürgen Schmidt (jsc, also to be seen in the CVS history). As I never use CVS for OOo, I just took for granted that the author of the *.java source file was the one indicated there, so here I go again: A reason to drop at least the $Author$ field from the legal headers, to avoid confusion? (I wonder, anyway, why RCSs are designed and used in a way where the RCS modifies the stored content---expanding $...$ fields---, as that cannot work in general.) But don't take this too seriously... :) -Stephan As you quoted my mail, let me tell you that I agree with you: I know this is a community project, but I like to know who is doing a great job, and may be you core developers would enjoy to hear from time to time some nice words from us! (considering the degree of aggressiveness some mails are taking :-( ) Bye, Ariel. -- Ariel Constenla-Haile La Plata, Argentina [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.arielconstenlahaile.com.ar/ooo/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] $Author$
Stephan Bergmann wrote: over at [EMAIL PROTECTED], Ariel Constenla-Haile wrote: Hi Frank, Frank Schönheit - Sun Microsystems Germany escribió: Hi Ariel, FIRST of all, I would like to thank the one who wrote the code of the GUI examples on the new SDK (OpenOffice.org_2.3_SDK/examples/DevelopersGuide/GUI): it answers some questions I had for a long time! Thanks hr (I don't know your real name!)! Hehe. hr (Jens-Heiner Rechtien) is a release engineer, who integrated the child workspace where this was introduced. While he, as all our release engineers, surely deserves thanks for the work he does, in this particular case please direct your thank to Jürgen Schmidt (jsc, also to be seen in the CVS history). As I never use CVS for OOo, I just took for granted that the author of the *.java source file was the one indicated there, so here I go again: A reason to drop at least the $Author$ field from the legal headers, to avoid confusion? (I wonder, anyway, why RCSs are designed and used in a way where the RCS modifies the stored content---expanding $...$ fields---, as that cannot work in general.) Yes, yes please let's do this. And while we are at it, let's remove the other $keywords$ as well. They really do make merges more complicated, without adding much of a value. But don't take this too seriously... :) Oh, I take this very serious :) Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
