Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
P
Postgres FD Implementation
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Abuhujair Javed
Postgres FD Implementation
Commits
89b1d255
Commit
89b1d255
authored
Nov 26, 2001
by
Bruce Momjian
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update FAQ_DEV.
parent
ea4f08ed
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
104 additions
and
4 deletions
+104
-4
doc/FAQ_DEV
doc/FAQ_DEV
+104
-4
No files found.
doc/FAQ_DEV
View file @
89b1d255
...
...
@@ -29,6 +29,7 @@
13) What is CommandCounterIncrement()?
14) Why don'
t
we
use
threads
in
the
backend
?
15
)
How
are
RPM
's packaged?
16) How are CVS branches handled?
_________________________________________________________________
1) What tools are available for developers?
...
...
@@ -36,18 +37,18 @@
Aside from the User documentation mentioned in the regular FAQ, there
are several development tools available. First, all the files in the
/tools directory are designed for developers.
RELEASE_CHANGES
changes we have to make for each release
SQL_keywords
standard SQL'
92
keywords
RELEASE_CHANGES changes we have to make for each release
SQL_keywords standard SQL'
92
keywords
backend
description
/
flowchart
of
the
backend
directories
ccsym
find
standard
defines
made
by
your
compiler
entab
converts
tabs
to
spaces
,
used
by
pgindent
find_static
finds
functions
that
could
be
made
static
find_typedef
finds
a
list
of
typedefs
in
the
source
code
find_typedef
finds
typedefs
in
the
source
code
find_badmacros
finds
macros
that
use
braces
incorrectly
make_ctags
make
vi
'tags'
file
in
each
directory
make_diff
make
*.
orig
and
diffs
of
source
make_etags
make
emacs
'etags'
files
make_keywords
.
README
make
comparison
of
our
keywords
and
SQL
'92
make_keywords
make
comparison
of
our
keywords
and
SQL
'92
make_mkid make mkid ID files
mkldexport create AIX exports file
pgindent indents C source files
...
...
@@ -530,3 +531,102 @@ stance. IMHO, of course.
Of course, there are many projects that DO include all the files
necessary to build RPMs from their Official Tarball (TM).
16) How are CVS branches managed?
This was written by Tom Lane:
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.
Also, Ian Lance Taylor points out that branches and tags can be
distiguished by using "
cvs
status
-
v
".
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment