Re: Proposal for the transition timetable for the move to GIT

Le 30/12/2019 à 01:18, Joseph Myers a écrit : Do "git log egcs_1_1_2_prerelease_2" in gcc-reparent, for example. The history ends up containing two different versions of SVN r5 and of many other commits. When trying to migrate Blender from svn to git, we actually tried git-svn first, and it

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 18:30, Ian Lance Taylor via gcc a écrit : On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD wrote: Which brings me to something I find strange in your policy: to me, merges from trunk to branches should be rare if not nonexistent. And you are deciding to banish merges

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Richard Earnshaw (lists) wrote: > gcc-reparent is better, but many (most?) of the release tags are shown > as merge commits with a fake parent back to the gcc-3 branch point, > which is certainly not what happened when the tagging was done at that > time. And looking at the h

Re: Proposal for the transition timetable for the move to GIT

On Sun, 2019-12-29 at 22:30 +0100, Thomas Koenig wrote: > Am 29.12.19 um 14:26 schrieb Segher Boessenkool: > > We cannot waste a year on a social experiment. We can slowly and carefully > > adopt new procedures, certainly. But anything drastic isn't advisable imo. > > > > Also, many GCC develope

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 11:00:08PM +, Joseph Myers wrote: > fixups in bugdb.py - and that way benefit both from reposurgeon making > choices that are as conservatively safe as possible, which seems a > desirable property for problem cases that haven't been manually reviewed, Problem cases t

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Eric S. Raymond wrote: > Joseph Myers : > > The case you mention is one where there was a merge to a branch not from > > its immediate parent but from an indirect parent. I don't think it would > > be hard to support detecting such merges in reposurgeon. > > We're working

Re: Git conversion: fixing email addresses from ChangeLog files

Richard Earnshaw (lists) : > Weak in the sense that it isn't proof given that the user name is > partially redacted. There's nothing in the gcc archives that gives a > full name either, unfortunately. > > Yes, it's the most likely match, but there's still an element of doubt. > > R. https://gro

Re: Git conversion: fixing email addresses from ChangeLog files

On Sun, 29 Dec 2019, Joseph Myers wrote: > I've now made those changes to the checked-in list so it's pure UTF-8, and > thus easier to review and edit. We still need to implement code in > bugdb.py to use that list to pick the preferred form from each list of > variants (and people may wish to

Re: Proposal for the transition timetable for the move to GIT

Joseph Myers : > The case you mention is one where there was a merge to a branch not from > its immediate parent but from an indirect parent. I don't think it would > be hard to support detecting such merges in reposurgeon. We're working on it. > This is an example where the originally added C

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Mark Wielaard wrote: > Maybe we should have a separate historical git repo which contains > everything that we were able to salvage and that people could git > remote add if they are really, really interested. I'm not convinced that's very different from having one repo with

gcc-10-20191229 is now available

Snapshot gcc-10-20191229 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20191229/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk

Re: The far past of GCC

On Sat, 28 Dec 2019, Jeff Law wrote: > I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. But I'm not aware of anyone still > having a copy of the old RCS ,v files. See ftp://gcc.gnu.org/pub/gcc/old-releases/old-cvs/ for the old repository (th

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 22:24, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> Also, for this one: >> >> # "47044": "", >> >> There's some (relatively weak) evidence that this is Bjørn Wennberg (eg >> https://groups.google.com/forum/#!msg/comp.databases.sybase/Uz8ICef9Qr8/uPwanH6is60J), >> but in the

Re: Git conversion: fixing email addresses from ChangeLog files

Richard Earnshaw (lists) : > Also, for this one: > > # "47044": "", > > There's some (relatively weak) evidence that this is Bjørn Wennberg (eg > https://groups.google.com/forum/#!msg/comp.databases.sybase/Uz8ICef9Qr8/uPwanH6is60J), > but in the absence of stronger evidence, I'm going to just pu

Re: Proposal for the transition timetable for the move to GIT

On 29/12/2019 18:30, Maxim Kuvyrkov wrote: > Below are several more issues I found in reposurgeon-6a conversion comparing > it against gcc-reparent conversion. > > I am sure, these and whatever other problems I may find in the reposurgeon > conversion can be fixed in time. However, I don't see

Re: Proposal for the transition timetable for the move to GIT

Am 29.12.19 um 14:26 schrieb Segher Boessenkool: We cannot waste a year on a social experiment. We can slowly and carefully adopt new procedures, certainly. But anything drastic isn't advisable imo. Also, many GCC developers aren't familiar with Git at all. It takes time to learn it, and to l

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Maxim Kuvyrkov wrote: > With the "Missed merges" problem (see below) I don't see how reposurgeon > conversion can be considered "ready". It aims to be conservatively safe regarding merges, erring on the side of not adding incorrect merges if in doubt. Because of the diffic

Re: Proposal for the transition timetable for the move to GIT

Below are several more issues I found in reposurgeon-6a conversion comparing it against gcc-reparent conversion. I am sure, these and whatever other problems I may find in the reposurgeon conversion can be fixed in time. However, I don't see why should bother. My conversion has been available

Re: Git conversion: fixing email addresses from ChangeLog files

On Sat, 28 Dec 2019, Joseph Myers wrote: > Concretely, what I'd suggest is: convert ISO-8859-1 entries in the > checked-in list to UTF-8, removing anything that thereby becomes a > duplicate or unnecessary; handle anything whose encoding isn't simply > ISO-8859-1 or UTF-8 via a hardcoded entry

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD wrote: > > Which brings me to something I find strange in your policy: to me, > merges from trunk to branches should be rare if not nonexistent. And you > are deciding to banish merges the other way around. Out of curiosity, why do you s

Re: Git conversion: fixing email addresses from ChangeLog files

On Sun, 2019-12-29 at 07:32 -0500, Eric S. Raymond wrote: > Richard Earnshaw (lists) : > > I've just commented that one out for now; if anybody knows the correct > > addresses, please let me know. Also, there's one joint list that I've > > not attempted to fix at this time. > > # "28488": "Jim Ki

Re: Proposal for the transition timetable for the move to GIT

Hi, On Wed, 2019-12-25 at 06:10 -0600, Segher Boessenkool wrote: > git-svn did not miss any branches. Finding branches is not done by > git-svn at all, for this. These branches were skipped because they > have nothing to do with GCC, have no history in common (they are not > descendants of revis

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 17:32, Richard Earnshaw a écrit : We agreed that for changes in our current workflow practices we'd defer that until *after* we'd switched to git; so this is getting off topic. On the other hand, we do need to sort out what we do with existing merge history, as that forms part of

Re: Proposal for the transition timetable for the move to GIT

On 29/12/2019 12:15, Segher Boessenkool wrote: > On Sun, Dec 29, 2019 at 12:02:51PM +0100, Richard Biener wrote: >> For bisecting trunk a merge would be a single commit, right? So I could see >> value in preserving a patch series where individual steps might introduce >> temporary issues as a bra

Re: Git conversion: fixing email addresses from ChangeLog files

On 29/12/2019 12:32, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> I've just commented that one out for now; if anybody knows the correct >> addresses, please let me know.  Also, there's one joint list that I've >> not attempted to fix at this time. > >> #  "28488": "Jim Kingdon

Re: The far past of GCC

Mark Wielaard : > Apparently less complete, but there is also > https://ftp.gnu.org/old-gnu/gcc/ > Which does have some old diff files to reconstruct some missing versions. There are quite a few ancient preserved release tarballs out there Here is the list of reconstructable pre-r3 releases as as

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 02:48:31PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: > >Merges aren't scary. Merges are inconvenient. > > No they are not. You are unaccustomed to them, which is different. Lol. Okay, end of discussion. You are assuming all the wrong things. Segher

Re: The far past of GCC

On Sat, Dec 28, 2019 at 09:15:53PM -0700, Jeff Law wrote: > I don't have a gitlab account, so I'm commenting here. > > I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. But I'm not aware of anyone still > having a copy of the old RCS ,v files.

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 14:31, Segher Boessenkool a écrit : On Sun, Dec 29, 2019 at 12:46:50PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: At worst, no commit is testable in the branch except the last, and git will say that the bug was introduced in the branch, which is not worse that what you'd get witho

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 14:26, Segher Boessenkool a écrit : Hi! On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: I'm not arguing that you should go that route, it seems a bit extreme to me. But outright refusing merges on the basis they are painful is (if you can accept the

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 12:46:50PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: > At worst, no commit is testable in the > branch except the last, and git will say that the bug was introduced in > the branch, which is not worse that what you'd get without a merge commit. We normally require every c

Re: Proposal for the transition timetable for the move to GIT

Hi! On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote: > I'm not arguing that you should go that route, it seems a bit extreme to > me. But outright refusing merges on the basis they are painful is (if > you can accept the strong word) ludicrous. They are painful for e

Re: The far past of GCC

> I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. Your memory agrees with mine.

Re: The far past of GCC

Jeff Law : > I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. That year sounds right - it's when I wrote the original vcs.el for Emacs and a lot of Emacs users who hadn't been usiing version control started to. Doesn't give us a Subversion rev

Re: Git conversion: fixing email addresses from ChangeLog files

Richard Earnshaw (lists) : > I've just commented that one out for now; if anybody knows the correct > addresses, please let me know. Also, there's one joint list that I've > not attempted to fix at this time. > # "28488": "Jim Kingdon ", That's Jim Kingdon the forme

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 12:02:51PM +0100, Richard Biener wrote: > For bisecting trunk a merge would be a single commit, right? So I could see > value in preserving a patch series where individual steps might introduce > temporary issues as a branch merge (after rebasing) so the series is visible

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 12:02, Richard Biener a écrit : On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool wrote: On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote: Oh, I'm not talking about historical merges. I'm saying we shouldn't do future merges, where we can

Re: Proposal for the transition timetable for the move to GIT

Le 29/12/2019 à 11:41, Segher Boessenkool a écrit : On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote: Oh, I'm not talking about historical merges. I'm saying we shouldn't do future merges, where we can help that. It disagrees with our documented "submitting patches" prot

Re: Proposal for the transition timetable for the move to GIT

On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool wrote: >On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud >wrote: >> >Oh, I'm not talking about historical merges. I'm saying we >shouldn't do >> >future merges, where we can help that. It disagrees with our >documen

Re: Proposal for the transition timetable for the move to GIT

On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote: > >Oh, I'm not talking about historical merges. I'm saying we shouldn't do > >future merges, where we can help that. It disagrees with our documented > >"submitting patches" protocol. > > I don't see how that can be correct