Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
2429c327
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
2429c327
编写于
11月 27, 2001
作者:
B
Bruce Momjian
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Update FAQ_DEV.
上级
f0074b60
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
32 addition
and
35 deletion
+32
-35
doc/src/FAQ/FAQ_DEV.html
doc/src/FAQ/FAQ_DEV.html
+32
-35
未找到文件。
doc/src/FAQ/FAQ_DEV.html
浏览文件 @
2429c327
...
...
@@ -545,24 +545,23 @@
<H3><A
name=
"15"
>
15
</A>
) How are RPM's packaged?
</H3>
<P>
This was written by Lamar Owen:
</P>
<P>
<P>
This was written by Lamar Owen:
</P>
<PRE>
As to how the RPMs are built -- to answer that question sanely requires
me to know how much experience you have with the whole RPM paradigm.
'How is the RPM built?' is a multifaceted question. The obvious simple
answer is that I maintain:
1.)
A set of patches to make certain portions of the source
tree 'behave' in the different environment of the RPMset;
2.)
The initscript;
3.)
Any other ancilliary scripts and files;
4.)
A README.rpm-dist document that tries to adequately document
both the differences between the RPM build and the WHY of the
differences, as well as useful RPM environment operations
(like, using syslog, upgrading, getting postmaster to
start at OS boot, etc);
5.)
The spec file that throws it all together. This is not a
trivial undertaking in a package of this size.
1.)
A set of patches to make certain portions of the source
tree 'behave' in the different environment of the RPMset;
2.)
The initscript;
3.)
Any other ancilliary scripts and files;
4.)
A README.rpm-dist document that tries to adequately document
both the differences between the RPM build and the WHY of the
differences, as well as useful RPM environment operations
(like, using syslog, upgrading, getting postmaster to
start at OS boot, etc);
5.)
The spec file that throws it all together. This is not a
trivial undertaking in a package of this size.
I then download and build on as many different canonical distributions
as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1 on
...
...
@@ -635,24 +634,23 @@ 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).
</PRE>
<P>
<H3><A
name=
"16"
>
16
</A>
) How are CVS branches managed?
</H3>
<P>
This was written by Tom Lane:
<
P>
<P>
This was written by Tom Lane:
</
P>
<PRE>
If you just do basic
"
cvs checkout
"
,
"
cvs update
"
,
"
cvs commit
"
, then
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
"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
"cvs log"
to any file that goes back a long time, for example HISTORY
in the top directory:
$ cvs log HISTORY | more
...
...
@@ -681,16 +679,16 @@ 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
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
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
...
...
@@ -705,25 +703,25 @@ 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
want to contain the toplevel
"pgsql"
directory and say
cvs ... checkout pgsql
cvs ... checkout pgsql
To get a past branch, you cd to whereever you want it and say
cvs ... checkout -r BRANCHNAME pgsql
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
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
"
:
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
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.
...
...
@@ -735,9 +733,8 @@ 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.
</PRE>
<P>
Also, Ian Lance Taylor points out that branches and tags can be
distiguished by using
"
cvs status -v
"
.
</P>
<P>
Also, Ian Lance Taylor points out that branches and tags can be
distiguished by using "cvs status -v".
</P>
</BODY>
</HTML>
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录