Re: Report: removing the inconsistencies in our CVS->git conversion
От | Robert Haas |
---|---|
Тема | Re: Report: removing the inconsistencies in our CVS->git conversion |
Дата | |
Msg-id | AANLkTi=bVBSFNHGgr7mw5M-Yjn547bwookcPZ+ftKW_u@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Report: removing the inconsistencies in our CVS->git conversion (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, Sep 13, 2010 at 1:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas@gmail.com> writes: >>>> I wonder if we should consider fixing some or all of these things on >>>> the master CVS repository. I wouldn't be too eager to inject those >>>> fake .0 commits for fear of breakage, but moving tags to where they >>>> ought to have been all along seems like it might be a good thing to do >>>> independent of git. > >>> Yeah, that's something I was wondering too. Applying these fixes to the >>> master repository would also reduce the number of things we have to >>> remember to do during the final conversion. OTOH, there's that risk of >>> breaking something. > >> Hand-written patches that apply directly to the RCS files seem like >> they'd be a risk for breakage, but I don't see why moving tags around >> would be all that dangerous, especially in cases where you can do it >> by running 'cvs' itself rather than 'rcs'. That should just be >> routine stuff, no? > > Hrm, well, keep in mind that most of these problems were *created* by > careless use of "cvs tag". At the moment I'm leaning towards the idea > that we should leave the CVS repository as it is, rather than take any > risk of making things worse. I think that I have never, and am never likely ever to, hear anyone describe you as careless. I feel pretty much 100% safe having you retag those releases to match the tarballs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: