- 浏览: 43263 次
- 性别:
- 来自: 上海
文章分类
最新评论
-
aiyanxu:
如果是通过脚手架来创建的controller,rails会默认 ...
Rails的命名惯例(Naming conventions) -
guji528:
详细演示sed功能,
sed -
nniu520:
我在hp unix上装的oracle10g,按“C、serve ...
Oracle修改字符集 -
robin5475:
引用rails在controller模块却又有不同的命名惯例: ...
Rails的命名惯例(Naming conventions) -
shgen:
如果是小的网站,要炫的效果,就用FLASH,如果是OA样的系统 ...
flash与服务器的交互
15. Example: Creating a new project from scratch
In this example a new project is started from scratch.
The project administrator must first create the CVS repository. In this example all project files will be stored in /home/projects/myproj and only the project members can access that directory. The project members must be in the grpname group. Please note how the "set-group-id" bit is set with the chmod command.
[Done on the CVS server]
# mkdir /home/projects/myproj
# mkdir /home/projects/myproj/cvsroot
# chgrp -R grpname /home/projects/myproj # change group
# chmod 2770 /home/projects/myproj # make group writable
# cvs -d /home/projects/myproj/cvsroot init # create the repository
or
[Done remotely]
# ssh mylogin@host.name.com mkdir -p /home/projects/myproj/cvsroot
# ssh mylogin@host.name.com chgrp -R grpname /home/projects/myproj
# ssh mylogin@host.name.com chmod 2770 /home/projects/myproj
# cvs -d mylogin@host.name.com:/home/projects/myproj/cvsroot init
Next we need an empty directory which will be imported as a new "project". The project is called src in the following example. Please note that foo and bar are required but not really used as the imported directory is empty.
# mkdir /tmp/src
# cd /tmp/src
# cvs -d johndoe@host.name.com:/home/projects/myproj/cvsroot \
import -m "" src foo bar
The project members can now start to add new files and make changes to files created by other members. New files can be added with cvs add filename, existing files modified and unwanted files removed with cvs rm -f filename. Modifications to the source tree should be reviewed with cvs diff -u before checking in the changes with cvs ci.
# cvs -d johndoe@host.name.com:/home/projects/myproj/cvsroot co src
# cd src
# vi extension.c
# cvs add extension.c # add a new file
# vi existingfile.c # modify an existing file
# cvs rm -f TODO # remove an existing file
# cvs update -dPA # what files were changed?
# cvs diff -u | less # see the modifications
# cvs ci -m "All TODOs implemented" TODO # remove the TODO file
# cvs ci -m "Added support for XYZ" # check in other files
# cvs update -dPA # update all files
16. Example: Project with third-party sources
In this example a new project is started based on some existing code. The code used in this project is Foo version 1.0.
The project administrator must first create the CVS repository. In this example all project files will be stored in /home/projects/myproj and only the project members can access that directory. The project members must be in the grpname group. Please note how the "set-group-id" bit is set with the chmod command.
[Done on the CVS server]
# mkdir -p /home/projects/myproj/cvsroot
# chgrp -R grpname /home/projects/myproj # change group
# chmod 2770 /home/projects/myproj # group writable
# cvs -d /home/projects/myproj/cvsroot init # create the repository
or
[Done remotely]
# ssh mylogin@host.name.com mkdir -p /home/projects/myproj/cvsroot
# ssh mylogin@host.name.com chgrp -R grpname /home/projects/myproj
# ssh mylogin@host.name.com chmod 2770 /home/projects/myproj
# cvs -d mylogin@host.name.com:/home/projects/myproj/cvsroot init
After creating an empty repository the project administrator must import the original Foo 1.0 sources into the FOO vendor branch. These source files will be located in the src/foo directory.
# cd /tmp
# tar xzf foo-1.0.tar.gz # extract the original files
# cd foo-1.0
# cvs -d mylogin@host.name.com:/home/projects/myproj/cvsroot import \
-I ! -I CVS -ko -m "Imported Foo 1.0" src/foo FOO FOO-1_0
The project members can now check out their own working copies and start making modifications and improvements. New files can be added with cvs add filename, existing files modified and unwanted files removed with cvs rm -f filename. Modifications to the source tree should be reviewed with cvs diff -u before checking in the changes with cvs ci.
# cvs -d johndoe@host.name.com:/home/projects/myproj/cvsroot co -P src
# cd src
# vi extension.c
# cvs add extension.c # add a new file
# vi existingfile.c # modify an existing file
# cvs rm -f config.log # remove an existing file
# cvs update -dPA # what files were changed?
# cvs diff -u | less # see the modifications
# cvs ci -m "Removed configuration log" config.log # remove the log file
# cvs ci -m "Added support for XYZ" # check in other files
# cvs update -dPA # update all files
Later when Foo 1.1 is released the project administrator can import the new release into the repository and merge changes made between versions 1.0 and 1.1 into the main developement branch (also known as HEAD).
[Import the new release]
# cd /tmp
# tar xzf foo-1.1.tar.gz # extract the new files
# cd foo-1.1
# cvs -d mylogin@host.name.com:/home/projects/myproj/cvsroot import \
-I ! -I CVS -ko -m "Imported Foo 1.1" src/foo FOO FOO-1_1
[Merge changes between official 1.0 and 1.1 releases into HEAD]
# cd ~/src/foo
# cvs update -d -kk -j FOO-1_0 -j FOO-1_1 # merge between 1.0 and 1.1
# cvs update | grep ^C # any conflicts?
[Fix possible conflicts]
# cvs ci -m "Upgraded Foo to version 1.1" # check in changes
# cvs update -dPA # update all files
Next time the project members update their working copies they will get the new Foo 1.1 sources.
In this example a new project is started from scratch.
The project administrator must first create the CVS repository. In this example all project files will be stored in /home/projects/myproj and only the project members can access that directory. The project members must be in the grpname group. Please note how the "set-group-id" bit is set with the chmod command.
[Done on the CVS server]
# mkdir /home/projects/myproj
# mkdir /home/projects/myproj/cvsroot
# chgrp -R grpname /home/projects/myproj # change group
# chmod 2770 /home/projects/myproj # make group writable
# cvs -d /home/projects/myproj/cvsroot init # create the repository
or
[Done remotely]
# ssh mylogin@host.name.com mkdir -p /home/projects/myproj/cvsroot
# ssh mylogin@host.name.com chgrp -R grpname /home/projects/myproj
# ssh mylogin@host.name.com chmod 2770 /home/projects/myproj
# cvs -d mylogin@host.name.com:/home/projects/myproj/cvsroot init
Next we need an empty directory which will be imported as a new "project". The project is called src in the following example. Please note that foo and bar are required but not really used as the imported directory is empty.
# mkdir /tmp/src
# cd /tmp/src
# cvs -d johndoe@host.name.com:/home/projects/myproj/cvsroot \
import -m "" src foo bar
The project members can now start to add new files and make changes to files created by other members. New files can be added with cvs add filename, existing files modified and unwanted files removed with cvs rm -f filename. Modifications to the source tree should be reviewed with cvs diff -u before checking in the changes with cvs ci.
# cvs -d johndoe@host.name.com:/home/projects/myproj/cvsroot co src
# cd src
# vi extension.c
# cvs add extension.c # add a new file
# vi existingfile.c # modify an existing file
# cvs rm -f TODO # remove an existing file
# cvs update -dPA # what files were changed?
# cvs diff -u | less # see the modifications
# cvs ci -m "All TODOs implemented" TODO # remove the TODO file
# cvs ci -m "Added support for XYZ" # check in other files
# cvs update -dPA # update all files
16. Example: Project with third-party sources
In this example a new project is started based on some existing code. The code used in this project is Foo version 1.0.
The project administrator must first create the CVS repository. In this example all project files will be stored in /home/projects/myproj and only the project members can access that directory. The project members must be in the grpname group. Please note how the "set-group-id" bit is set with the chmod command.
[Done on the CVS server]
# mkdir -p /home/projects/myproj/cvsroot
# chgrp -R grpname /home/projects/myproj # change group
# chmod 2770 /home/projects/myproj # group writable
# cvs -d /home/projects/myproj/cvsroot init # create the repository
or
[Done remotely]
# ssh mylogin@host.name.com mkdir -p /home/projects/myproj/cvsroot
# ssh mylogin@host.name.com chgrp -R grpname /home/projects/myproj
# ssh mylogin@host.name.com chmod 2770 /home/projects/myproj
# cvs -d mylogin@host.name.com:/home/projects/myproj/cvsroot init
After creating an empty repository the project administrator must import the original Foo 1.0 sources into the FOO vendor branch. These source files will be located in the src/foo directory.
# cd /tmp
# tar xzf foo-1.0.tar.gz # extract the original files
# cd foo-1.0
# cvs -d mylogin@host.name.com:/home/projects/myproj/cvsroot import \
-I ! -I CVS -ko -m "Imported Foo 1.0" src/foo FOO FOO-1_0
The project members can now check out their own working copies and start making modifications and improvements. New files can be added with cvs add filename, existing files modified and unwanted files removed with cvs rm -f filename. Modifications to the source tree should be reviewed with cvs diff -u before checking in the changes with cvs ci.
# cvs -d johndoe@host.name.com:/home/projects/myproj/cvsroot co -P src
# cd src
# vi extension.c
# cvs add extension.c # add a new file
# vi existingfile.c # modify an existing file
# cvs rm -f config.log # remove an existing file
# cvs update -dPA # what files were changed?
# cvs diff -u | less # see the modifications
# cvs ci -m "Removed configuration log" config.log # remove the log file
# cvs ci -m "Added support for XYZ" # check in other files
# cvs update -dPA # update all files
Later when Foo 1.1 is released the project administrator can import the new release into the repository and merge changes made between versions 1.0 and 1.1 into the main developement branch (also known as HEAD).
[Import the new release]
# cd /tmp
# tar xzf foo-1.1.tar.gz # extract the new files
# cd foo-1.1
# cvs -d mylogin@host.name.com:/home/projects/myproj/cvsroot import \
-I ! -I CVS -ko -m "Imported Foo 1.1" src/foo FOO FOO-1_1
[Merge changes between official 1.0 and 1.1 releases into HEAD]
# cd ~/src/foo
# cvs update -d -kk -j FOO-1_0 -j FOO-1_1 # merge between 1.0 and 1.1
# cvs update | grep ^C # any conflicts?
[Fix possible conflicts]
# cvs ci -m "Upgraded Foo to version 1.1" # check in changes
# cvs update -dPA # update all files
Next time the project members update their working copies they will get the new Foo 1.1 sources.
发表评论
-
ccccccc
2011-06-09 18:02 0c language book. -
economic books
2011-05-23 10:02 0books for ecnomic. -
简历11111
2011-05-10 23:47 0推荐简历。 -
impatient perl
2011-04-26 21:22 869impatient perl book. -
resume...
2011-02-13 20:40 0resume.... -
suibian
2010-10-23 10:40 0fsdafasdfsadfas -
aaaa
2010-05-31 18:24 0c programing language -
cpp
2010-04-29 16:21 0cpp books -
eclipse vim plugin
2010-04-27 10:55 0plgin -
转增股和送股
2009-10-07 18:58 0送股:是上市公司将本年的利润留在公司里,发放股票作为红利,从而 ... -
开发人员和测试人员的交流
2009-09-21 17:31 898今天经理(刚从美国回来)给我们发表了一篇激情的演讲《开 ... -
getopts
2009-08-12 10:28 0gdfgfgfhfgh -
perl 内置特殊变量
2009-08-09 22:26 870[size=medium]$- 当前页可打印的行数,属于Per ... -
CVS create respository
2009-07-31 11:21 1549Creating a CVS Repository by J ... -
Linux 终端命令
2009-04-04 00:37 1126[size=medium]玩儿转Linux:终端命令用法精选 ... -
初入职场
2008-11-01 22:29 703看了童继龙先生的一篇博文,感想很大。公司最近做项目,很 ...
相关推荐
火龙果软件工程技术中心 cvs版本:CVSNT_2.5.02在本地磁盘创建个存放CVS文件的文件夹,本实例在E:\CvsWorkSpace1.安装完cvs之后,在开始->程序->CVSNT->CVSNTControlPanel.出现如下界面2.选择在本地存放CVS文件夹的...
TortoiseCVS则将CVS的功能集成到Windows资源管理器中,提供了直观易用的图形用户界面,极大地简化了CVS的操作流程。 **CVS基础概念** 1. **版本控制**:版本控制系统记录了文件和目录的历史更改,允许用户回溯到...
这些基本操作构成了CVS的核心流程,让团队能够高效地协同开发。 然而,随着Git等更现代的版本控制系统的发展,CVS的市场份额逐渐被取代。Git提供了更快的速度、更强的分支管理能力和更直观的工作流。但这并不意味着...
**TortoiseCVS使用流程** 1. **安装与配置**:下载并安装TortoiseCVS,设置CVS服务器地址、用户信息等。 2. **连接版本库**:通过资源管理器访问CVS服务器,检出项目到本地。 3. **日常开发**:在工作副本中编辑...
CVS(Concurrent Versions System)是一种广泛使用的源代码版本控制...Git提供了更快的速度、更强大的分支管理和更直观的用户界面,但CVS仍然在某些项目和组织中得到应用,特别是在那些已经习惯其工作流程的环境中。
4. **工作流程**:学习CVS的标准工作流程,包括获取项目、创建分支、开发新功能、合并代码和发布版本等步骤。 5. **冲突处理**:理解并掌握在多个人同时编辑同一文件时可能出现的冲突情况,学会使用CVS工具来解决...
**CVS的工作流程:** 1. 开发者在本地计算机上安装CVS客户端。 2. 使用CVS命令行工具或集成开发环境(如NetBeans)连接到CVS服务器。 3. 从服务器签出项目的一个副本到本地。 4. 在本地编辑代码,完成任务。 5. ...
三、CVS配置流程 1. 创建仓库:例如创建名为“dir_php”的仓库,用于存放网站文件。 2. 打开CVSNT控制面板,选择Repository configuration选项卡,配置仓库路径。 3. 在Server Settings选项卡中,设置运行方式...
3. **CVS的工作流程** - **初始化**:在服务器上创建CVS仓库,导入初始项目文件。 - **获取工作副本**:开发者在本地执行`cvs checkout`命令,得到项目副本。 - **编辑与提交**:开发者修改本地文件后,使用`cvs ...
学习和理解CVS的工作原理和使用方法,对于理解现代版本控制概念以及协作开发的流程有着重要的意义。通过阅读提供的"CVS安装程序和课件",你可以深入了解CVS的安装和使用,从而更好地利用这个工具进行团队开发。
2. **测试**:在大规模转换前,先在一个小规模的CVS仓库上进行试验,以熟悉流程并检查结果。 3. **冲突处理**:虽然cvs2svn尽力处理分支和合并,但可能会出现冲突,需要手动解决。 4. **日志消息**:cvs2svn可能...
安装同样为标准的软件安装流程,包括接受许可协议、选择安装位置等。 - **3.2 配置**:配置Wincvs需要设置CVS服务器的连接信息,如主机地址、端口、用户名、密码等,以便客户端能够连接到服务器进行版本控制操作。 ...
### Eclipse中CVS操作详解 ...正确安装配置CVS服务器,理解基本的使用流程,是高效利用这一工具的关键。无论是对于个人开发者还是团队协作,掌握CVS的基本操作都能显著提升项目管理和版本控制的能力。
本文将基于给定的文件信息,详细介绍CVS在Windows XP操作系统下的安装与配置流程,帮助读者理解和掌握CVS的基本操作。 #### 一、CVS安装步骤 1. **下载安装文件**:首先,需要从官方网站或其他可信源下载CVS的安装...
3. 工作流程:指导用户如何高效地使用CVS进行日常开发,如检出新项目、解决合并冲突、查看差异等。 4. 分支与合并:解释如何创建、切换和合并分支,以及处理分支中的冲突策略。 5. 权限管理:讲解如何设置用户权限,...
### 使用CVS的工作流程 1. **初始化(Initialization)**:在服务器上创建CVS仓库,导入项目文件。 2. **获取工作拷贝(Checkout)**:开发者从仓库中获取最新版本的代码到本地工作拷贝。 3. **编辑与提交(Edit ...
CVS(Concurrent Versions System)是一种版本控制系统,用于管理软件项目的源代码和其他文件。这个“CVS中文操作手册”提供了一套详细的...通过深入学习和实践,你可以熟练掌握CVS,实现高效、可靠的软件开发流程。
源码管理是软件开发流程中不可或缺的一环,cvs作为一个工具,使得开发者可以跟踪代码的每一次修改,回溯历史版本,解决冲突,进行分支管理等。它支持多人同时编辑,避免了因代码同步问题导致的混乱。 在【压缩包子...
6. 工作流程: - CVS:`cvs add`添加新文件,`cvs commit`提交更改,`cvs update`获取他人更新,`cvs diff`查看差异,`cvs merge`合并分支。 - SVN:`svn add`和`svn commit`对应CVS的操作,此外`svn status`查看...