Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
On 03/29/2012 09:54 PM, Ivan Maidanski wrote: Hi Andrew, Thank you for the explanation. Thu, 29 Mar 2012 18:33:45 +0100 Andrew Haley a...@redhat.com: On 03/29/2012 06:19 PM, Ivan Maidanski wrote: Hi Andrew, Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley a...@redhat.com: On 03/29/2012 04:58 PM, Ivan Maidanski wrote: It would be good to deprecate ChangeLog (used as commit log) as well. Why? I think this sentence is missing a because ... clause. Sorry for not explaining you how does git merge work. if you don't have a special ChangeLog-aware merge driver installed (like git-merge-changelog) you would almost always get merge conflicts when pulling public modifications into a privately modified ChangeLog file (same for rebasing). Every merge conflict requires manual handling. If it is decided to move to VCS that simplifies parallel development and branch merging, staying with old commit policy (relying on ChangeLog) neutralizes that benefits. But that's what the git ChangeLog plugin is for. GNU projects have ChangeLogs; The plugin is merely a workaround. I don't understand this comment. The plugin makes git handle ChangeLogs correctly; there are plugins to make it handle other formats correctly, too. You say GNU projects have X Why? (because is missing) Because the ChangeLog is useful to have, independently of any particular VCS. You you put ChangeLog to ignored list and regenerate on tarball release via git log would it be possible to say the project has ChangeLog or not? As long as there is a ChangeLog, it doesn't matter at all how it is created, as long as it's correct, complete, and properly formatted. In any case, let's not have this mailing list degenerate into my VCS versus yours flame wars, just like every other list. Agree but if there is a choice - augmented pros and cons are generally welcomed. But I don't think there is a choice. It's too late, so all this discussion is moot. Andrew.
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
On 03/30/2012 09:17 AM, Andrew Haley wrote: You you put ChangeLog to ignored list and regenerate on tarball release via git log would it be possible to say the project has ChangeLog or not? As long as there is a ChangeLog, it doesn't matter at all how it is created, as long as it's correct, complete, and properly formatted. One thing I forgot to mention: tooling is critical. I don't have to create properly-formatted ChangeLog entries by myself because there are tools to do it. Any change to policies requires complete tooling support or people will waste time having to generate entries by hand. Andrew.
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
- Original Message - CVSROOT: /sources/classpath Module name: classpath Changes by: Andrew Haley aph 12/03/29 09:32:34 Modified files: . : ChangeLog native/jni/java-io: java_io_VMConsole.c Log message: 2012-03-25 Gerald Pfeifer ger...@pfeifer.com PR libgcj/52694 * native/jni/java-io/java_io_VMConsole.c (IUCLC): Define, if undefined. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9848r2=1.9849 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-io/java_io_VMConsole.c?cvsroot=classpathr1=1.1r2=1.2 The CVS repository is obsolete. Current development takes place in git: http://git.savannah.gnu.org/cgit/classpath.git See this thread: http://developer.classpath.org/pipermail/classpath/2012-March/003181.html -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
On 03/29/2012 03:52 PM, Andrew Hughes wrote: The CVS repository is obsolete. Current development takes place in git: I missed that. OK, I'll push the patch to git. We need at least to make the CVS read-only. Why are we using yet another VCS, anyway? We can pretty much guarantee that free Java devs are used to Mercural and maybe Subversion, but git? Andrew.
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
Andrew Haley wrote: Why are we using yet another VCS, anyway? We can pretty much guarantee that free Java devs are used to Mercural and maybe Subversion, but git? Because nobody spoke up during the review period, so the first suggestion was accepted.
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
On 03/29/2012 04:12 PM, Chris Burdess wrote: Because nobody spoke up during the review period, so the first suggestion was accepted. Yes, I'm sure that's the meta-reason, and I should have been paying more attention. :-( Andrew.
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
Hi Andrew, It would be good to deprecate ChangeLog (used as commit log) as well. Regards. Thu, 29 Mar 2012 10:52:26 -0400 (EDT) Andrew Hughes ahug...@redhat.com: - Original Message - CVSROOT:/sources/classpath Module name:classpath Changes by: Andrew Haley aph 12/03/29 09:32:34 Modified files: . : ChangeLog native/jni/java-io: java_io_VMConsole.c Log message: 2012-03-25 Gerald Pfeifer ger...@pfeifer.com PR libgcj/52694 * native/jni/java-io/java_io_VMConsole.c (IUCLC): Define, if undefined. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9848r2=1.9849 http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-io/java_io_VMConsole.c?cvsroot=classpathr1=1.1r2=1.2 The CVS repository is obsolete. Current development takes place in git: http://git.savannah.gnu.org/cgit/classpath.git See this thread: http://developer.classpath.org/pipermail/classpath/2012-March/003181.html -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
On Thu, Mar 29, 2012 at 6:07 PM, Andrew Haley a...@redhat.com wrote: Why are we using yet another VCS, anyway? We can pretty much guarantee that free Java devs are used to Mercural and maybe Subversion, but git? FWIW, I voted for git because that's what I know. I have never used Mercurial for real work. Pekka
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
On 03/29/2012 04:58 PM, Ivan Maidanski wrote: It would be good to deprecate ChangeLog (used as commit log) as well. Why? I think this sentence is missing a because ... clause. Andrew.
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
Hi Andrew, Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley a...@redhat.com: On 03/29/2012 04:58 PM, Ivan Maidanski wrote: It would be good to deprecate ChangeLog (used as commit log) as well. Why? I think this sentence is missing a because ... clause. Sorry for not explaining you how does git merge work. if you don't have a special ChangeLog-aware merge driver installed (like git-merge-changelog) you would almost always get merge conflicts when pulling public modifications into a privately modified ChangeLog file (same for rebasing). Every merge conflict requires manual handling. If it is decided to move to VCS that simplifies parallel development and branch merging, staying with old commit policy (relying on ChangeLog) neutralizes that benefits. PS. I was surprised to hear that free Java developers prefer SVN to Git. How many free Java developers have been contributing to Classpath over the passed 3-4 years? And which of them prefer to stay with CVS and SVN? Regards. Andrew.
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
On 03/29/2012 06:19 PM, Ivan Maidanski wrote: Hi Andrew, Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley a...@redhat.com: On 03/29/2012 04:58 PM, Ivan Maidanski wrote: It would be good to deprecate ChangeLog (used as commit log) as well. Why? I think this sentence is missing a because ... clause. Sorry for not explaining you how does git merge work. if you don't have a special ChangeLog-aware merge driver installed (like git-merge-changelog) you would almost always get merge conflicts when pulling public modifications into a privately modified ChangeLog file (same for rebasing). Every merge conflict requires manual handling. If it is decided to move to VCS that simplifies parallel development and branch merging, staying with old commit policy (relying on ChangeLog) neutralizes that benefits. But that's what the git ChangeLog plugin is for. GNU projects have ChangeLogs; it's up to the VCS to keep up. PS. I was surprised to hear that free Java developers prefer SVN to Git. So was I. Who said that Java developers prefer SVN to Git? How many free Java developers have been contributing to Classpath over the passed 3-4 years? And which of them prefer to stay with CVS and SVN? Well, I vastly prefer SVN to anything I've seen recently because of its branch handling, but maybe that's only me. In any case, let's not have this mailing list degenerate into my VCS versus yours flame wars, just like every other list. Andrew.
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
Hi Andrew, Thank you for the explanation. Thu, 29 Mar 2012 18:33:45 +0100 Andrew Haley a...@redhat.com: On 03/29/2012 06:19 PM, Ivan Maidanski wrote: Hi Andrew, Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley a...@redhat.com: On 03/29/2012 04:58 PM, Ivan Maidanski wrote: It would be good to deprecate ChangeLog (used as commit log) as well. Why? I think this sentence is missing a because ... clause. Sorry for not explaining you how does git merge work. if you don't have a special ChangeLog-aware merge driver installed (like git-merge-changelog) you would almost always get merge conflicts when pulling public modifications into a privately modified ChangeLog file (same for rebasing). Every merge conflict requires manual handling. If it is decided to move to VCS that simplifies parallel development and branch merging, staying with old commit policy (relying on ChangeLog) neutralizes that benefits. But that's what the git ChangeLog plugin is for. GNU projects have ChangeLogs; The plugin is merely a workaround. You say GNU projects have X Why? (because is missing) You you put ChangeLog to ignored list and regenerate on tarball release via git log would it be possible to say the project has ChangeLog or not? ... it's up to the VCS to keep up. VCS could keep everything you put - e.g. auto-generated files and binaries - it's up to you decide what's suitable for you when doing basic tasks. E.g., Classpath repo has .svnignore files - if moved to git we could create .gitignore by ln -s for each one (putting .svningore to .git exclude file) - a working solution while keeping compatibility with SVN but will it be as convenient as native .gitignore (e.g., in case of cloning)? (I guess there probably exists some driver that emulates .gitignore based on .svn/cvsignore present but I'm not sure.) PS. I was surprised to hear that free Java developers prefer SVN to Git. So was I. Who said that Java developers prefer SVN to Git? How many free Java developers have been contributing to Classpath over the passed 3-4 years? And which of them prefer to stay with CVS and SVN? Well, I vastly prefer SVN to anything I've seen recently because of its branch handling, but maybe that's only me. If you could be here more verbose or give a link - would be appreciated. Thanks. In any case, let's not have this mailing list degenerate into my VCS versus yours flame wars, just like every other list. Agree but if there is a choice - augmented pros and cons are generally welcomed. Regards. Andrew.
Re: [cp-patches] [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...
- Original Message - On 03/29/2012 06:19 PM, Ivan Maidanski wrote: Hi Andrew, Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley a...@redhat.com: On 03/29/2012 04:58 PM, Ivan Maidanski wrote: It would be good to deprecate ChangeLog (used as commit log) as well. Why? I think this sentence is missing a because ... clause. Sorry for not explaining you how does git merge work. if you don't have a special ChangeLog-aware merge driver installed (like git-merge-changelog) you would almost always get merge conflicts when pulling public modifications into a privately modified ChangeLog file (same for rebasing). Every merge conflict requires manual handling. If it is decided to move to VCS that simplifies parallel development and branch merging, staying with old commit policy (relying on ChangeLog) neutralizes that benefits. But that's what the git ChangeLog plugin is for. GNU projects have ChangeLogs; it's up to the VCS to keep up. PS. I was surprised to hear that free Java developers prefer SVN to Git. So was I. Who said that Java developers prefer SVN to Git? How many free Java developers have been contributing to Classpath over the passed 3-4 years? And which of them prefer to stay with CVS and SVN? Well, I vastly prefer SVN to anything I've seen recently because of its branch handling, but maybe that's only me. In any case, let's not have this mailing list degenerate into my VCS versus yours flame wars, just like every other list. Yes, let's not. I'll just say that from my side, working with individual changesets makes it a lot easier to dig out individual patches, etc. Doing the recent gcj merge with SVN was horrendous compared with the OpenJDK merges I do (though gcc is a much bigger repo) and I think things would be a lot harder if OpenJDK used it. git and mercurial seem pretty much the same to me, the main difference being that mercurial seems to trail git in terms of feature development and git has a usable branch system, rather than the fakery we have to do with mercurial. Andrew. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
