Re: CVS branch management (was Re: A problem with new pg_dump)
От | Bruce Momjian |
---|---|
Тема | Re: CVS branch management (was Re: A problem with new pg_dump) |
Дата | |
Msg-id | 200111271825.fARIPbr01159@candle.pha.pa.us обсуждение исходный текст |
Ответ на | CVS branch management (was Re: A problem with new pg_dump) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
I have added this to the developer's FAQ. --------------------------------------------------------------------------- > Philip Warner <pjw@rhyme.com.au> writes: > > At 11:22 7/05/01 -0400, Tom Lane wrote: > >> Do you need a quick lecture on CVS branch management? > > > That would be sensible. > > OK, some quick notes for those with commit privileges: > > If you just do basic "cvs checkout", "cvs update", "cvs commit", then > you'll always be dealing with the HEAD version of the files in CVS. > That's what you want for development, but if you need to patch past > stable releases then you have to be able to access and update the > "branch" portions of our CVS repository. We normally fork off a branch > for a stable release just before starting the development cycle for the > next release. > > The first thing you have to know is the branch name for the branch you > are interested in getting at. Unfortunately Marc has been less than > 100% consistent in naming the things. One way to check is to apply > "cvs log" to any file that goes back a long time, for example HISTORY > in the top directory: > > $ cvs log HISTORY | more > > RCS file: /home/projects/pgsql/cvsroot/pgsql/HISTORY,v > Working file: HISTORY > head: 1.106 > branch: > locks: strict > access list: > symbolic names: > REL7_1_STABLE: 1.106.0.2 > REL7_1_BETA: 1.79 > REL7_1_BETA3: 1.86 > REL7_1_BETA2: 1.86 > REL7_1: 1.102 > REL7_0_PATCHES: 1.70.0.2 > REL7_0: 1.70 > REL6_5_PATCHES: 1.52.0.2 > REL6_5: 1.52 > REL6_4: 1.44.0.2 > release-6-3: 1.33 > SUPPORT: 1.1.1.1 > PG95-DIST: 1.1.1 > keyword substitution: kv > total revisions: 129; selected revisions: 129 > More---q > > Unfortunately "cvs log" isn't all that great about distinguishing > branches from tags --- it calls 'em all "symbolic names". (A "tag" just > marks a specific timepoint across all files --- it's essentially a > snapshot whereas a branch is a changeable fileset.) Rule of thumb is > that names attached to four-number versions where the third number is > zero represent branches, the others are just tags. Here we can see that > the extant branches are > REL7_1_STABLE > REL7_0_PATCHES > REL6_5_PATCHES > The next commit to the head will be revision 1.107, whereas any changes > committed into the REL7_1_STABLE branch will have revision numbers like > 1.106.2.*, corresponding to the branch number 1.106.0.2 (don't ask where > the zero went...). > > OK, so how do you do work on a branch? By far the best way is to create > a separate checkout tree for the branch and do your work in that. Not > only is that the easiest way to deal with CVS, but you really need to > have the whole past tree available anyway to test your work. (And you > *better* test your work. Never forget that dot-releases tend to go out > with very little beta testing --- so whenever you commit an update to a > stable branch, you'd better be doubly sure that it's correct.) > > Normally, to checkout the head branch, you just cd to the place you > want to contain the toplevel "pgsql" directory and say > > cvs ... checkout pgsql > > To get a past branch, you cd to whereever you want it and say > > cvs ... checkout -r BRANCHNAME pgsql > > For example, just a couple days ago I did > > mkdir ~postgres/REL7_1 > cd ~postgres/REL7_1 > cvs ... checkout -r REL7_1_STABLE pgsql > > and now I have a maintenance copy of 7.1.*. > > When you've done a checkout in this way, the branch name is "sticky": > CVS automatically knows that this directory tree is for the branch, > and whenever you do "cvs update" or "cvs commit" in this tree, you'll > fetch or store the latest version in the branch, not the head version. > Easy as can be. > > So, if you have a patch that needs to apply to both the head and a > recent stable branch, you have to make the edits and do the commit > twice, once in your development tree and once in your stable branch > tree. This is kind of a pain, which is why we don't normally fork > the tree right away after a major release --- we wait for a dot-release > or two, so that we won't have to double-patch the first wave of fixes. > > Any questions? (See the CVS manual for details on these commands, > of course.) > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Bruce MomjianДата:
Сообщение: Re: CVS branch management (was Re: A problem with new pg_dump)