Re: [commit-cp] classpath ChangeLog native/jni/java-io/java_io_...

[Andrew Hughes-7]

----- 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  <gerald@...>
>
>        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=classpath&r1=1.9848&r2=1.9849
> http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-io/java_io_VMConsole.c?cvsroot=classpath&r1=1.1&r2=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

[Andrew Haley]

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.

[Chris Burdess-2]

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.

[Andrew Haley]

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.

[Ivan Maidanski]

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 <ahughes@...>:

> ----- 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  <gerald@...>
> >
> >        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=classpath&r1=1.9848&r2=1.9849
> > http://cvs.savannah.gnu.org/viewcvs/classpath/native/jni/java-io/java_io_VMConsole.c?cvsroot=classpath&r1=1.1&r2=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
>
>
>

[Pekka Enberg-4]

On Thu, Mar 29, 2012 at 6:07 PM, Andrew Haley <aph@...> 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

[Andrew Haley]

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.

[Ivan Maidanski]

Hi Andrew,

Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley <aph@...>:
> 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.

[Andrew Haley]

On 03/29/2012 06:19 PM, Ivan Maidanski wrote:

> Hi Andrew,
>
> Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley <aph@...>:
>> 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.

[Ivan Maidanski]

Hi Andrew,

Thank you for the explanation.

Thu, 29 Mar 2012 18:33:45 +0100 Andrew Haley <aph@...>:

> On 03/29/2012 06:19 PM, Ivan Maidanski wrote:
> > Hi Andrew,
> >
> > Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley <aph@...>:
> >> 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.
>

[Andrew Hughes-7]

----- Original Message -----

> On 03/29/2012 06:19 PM, Ivan Maidanski wrote:
> > Hi Andrew,
> >
> > Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley <aph@...>:
> >> 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

[Andrew Haley]

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 <aph@...>:
>> On 03/29/2012 06:19 PM, Ivan Maidanski wrote:
>>> Hi Andrew,
>>>
>>> Thu, 29 Mar 2012 17:42:17 +0100 от Andrew Haley <aph@...>:
>>>> 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.

[Andrew Haley]

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.