SVN常用目录结构

最新推荐文章于 2024-04-28 10:32:16 发布
最新推荐文章于 2024-04-28 10:32:16 发布
阅读量1.3k 收藏 3
点赞数
文章标签： svn branch merge 文档 任务 subversion
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dinamica/article/details/4567012
版权

特殊目录名说明

 trunk 主干,存储最新稳定版本
tag 标记,主要保存比较完整理的版本标记,类似里程碑
tranch 分支,用于分工操作.该目录下又以各用户名及日期为目录进行存储(推荐)

关于目录(结构举例,相对规范)

/doc 文档的 根目录

/doc/trunk 文档的 版本主干,存储最新稳定版本
/doc/trunk/...(内容)
/doc/tag 文档的 版本标志(类似里程碑)例如: doc_1_0/doc_1_1 分别表是1.0本版与1.1版本
/doc/tag/doc_v_1_0/...(内容)
/doc/tag/doc_v_1_1/...(内容)

/doc/branch 文档的 分支目录(用户分工)
/doc/branch/user1_070308 文档的 分支目录用户(user1)于2007-03-08号加入分工
/doc/branch/user1_070308/...(内容)

/doc/branch/user2_070101 文档的 分支目录用户(user2)于2007-01-01号加入分工
/doc/branch/user2_070101/...(内容)

/src 源码的 根目录

/src/trunk 源码的 版本主干,存储最新稳定版本
/src/trunk/...(内容)
/src/tag 源码的 版本标志(类似里程碑)例如: doc_1_0/prj_src_1_1 分别表是1.0本版与1.1版本
/src/tag/prj_src_v_1_0/...(内容)
/src/tag/prj_src_v_1_1/...(内容)

/src/branch 源码的 分支目录(用户分工)
/src/branch/user1_070308 源码的 分支目录用户(user1)于2007-03-08号加入分工
/src/branch/user1_070308/...(内容)

/src/branch/user2_070101 源码的 分支目录用户(user2)于2007-01-01号加入分工
/src/branch/user2_070101/...(内容)

 

Subversion有一个很标准的目录结构，是这样的。
比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是

svn://proj/

|

+-trunk

+-branches

+-tags

这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。

对于这几个开发目录，一般的使用方法有两种。我更多的是从软件产品的角度出发（比如freebsd），因为互联网的开发模式是完全不一样的。
第一种方法，使用trunk作为主要的开发目录。
一 般的，我们的所有的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处 于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk进 行开发。
此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支（branch）进行开发。
例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。
按照时间的顺序

  1. 1.0开发完毕，代码冻结
  2. 基于已经冻结的trunk，为release1.0打tag
    此时的目录结构为
    svn://proj/
                 +trunk/  (freeze)
                 +branches/
                 +tags/
                         +tag_release_1.0　(copy from trunk)
  3. 2.0开始开发，trunk此时为2.0的开发版
  4. 发现1.0有bug，需要修改，基于1.0的tag做branch
    此时的目录结构为
    svn://proj/
                 +trunk/  ( dev 2.0 )
                 +branches/
                               +dev_1.0_bugfix (copy from tag/release_1.0)
                 +tags/
                         +release_1.0　(copy from trunk)
  5. 在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发
  6. 在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等
  7. 根据需要选择性的把dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）

这是一种很标准的开发模式，很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

第二种方法，在每一个release的branch中进行各自的开发，trunk只做发布使用。
这种开发模式当中，trunk是不承担具体开发任务的，一个版本/阶段的开发任务在开始的时候，根据已经release的版本做新的开发分支，并且基于这个分支进行开发。还是举上面的例子，这里面的时序关系是。

  1. 1.0开发，做dev1.0的branch
    此时的目录结构
    svn://proj/
                 +trunk/  (不担负开发任务 )
                 +branches/
                               +dev_1.0 (copy from trunk)
                 +tags/
  2. 1.0开发完成，merge dev1.0到trunk
    此时的目录结构
    svn://proj/
                 +trunk/  (merge from branch dev_1.0)
                 +branches/
                               +dev_1.0 (开发任务结束，freeze)
                 +tags/
  3. 根据trunk做1.0的tag
    此时的目录结构
    svn://proj/
                 +trunk/  (merge from branch dev_1.0)
                 +branches/
                               +dev_1.0 (开发任务结束，freeze)
                 +tags/
                         +tag_release_1.0 (copy from trunk)
  4. 1.0开发，做dev2.0分支
    此时的目录结构
    svn://proj/
                 +trunk/ 
                 +branches/
                               +dev_1.0 (开发任务结束，freeze)
                               +dev_2.0 （进行2.0开发）
                 +tags/
                         +tag_release_1.0 (copy from trunk)
  5. 1.0有bug，直接在dev1.0的分支上修复
    此时的目录结构
    svn://proj/
                 +trunk/ 
                 +branches/
                               +dev_1.0 (1.0bugfix)
                               +dev_2.0 （进行2.0开发）
                 +tags/
                         +tag_release_1.0 (copy from trunk)
  6. 选择性的进行代码merge

这其实是一种分散式的开发，当各个部分相对独立一些（功能性的），可以开多个dev的分支进行开发，这样各人/组都不会相互影响。比如dev_2.0_search和dev_2.0_cache等。但是这样merge起来就是一个很痛苦的事情。

这 里要注意一下的，第六步进行选择性的merge，是可以当2.0开发结束后一起把dev_1.0（bugfix用）和dev_2.0（新版本开发 用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，进行测试等之后再merge回trunk。
这两种方法各有利弊，第一种方法是可以得到一个比较纯的dev_2.0的开发分支，而第二种方法则更加的保险，因为要测试嘛。

以上呢，就是我说的两种开发模式了，具体哪种好，并没有定论。这里大致的说一下各自的优缺点
第一种开发模式（trunk进行主要开发，集中式）：
优点：管理简单
缺点：当开发的模块比较多，开发人数/小团队比较多的时候，很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动
第二重开发模式（分支进行主要开发，分散式）：
优点：各自开发独立，不容易相互影响。
缺点：管理复杂，merge的时候很麻烦，容易死人。

其实，这里并没有一定之规，更多的时候是两种模式结合使用。我个人来说是采用第一种方式为主，在某些情况下使用第二种方法。

dinamica
关注
  • 0
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SVN操作手册中文版网页格式
11-08
针对打不开chm格式的网友 转换后为网页格式的<SVN操作手册中文版> 目录 译者序 前言 序言 读者 怎样阅读本书 本书约定 排版习惯 图标 本书组织结构 Subversion 1.1的新特性,svn客户端和linux下命令行。 目录 1. 简介 1.1. 什么是 TortoiseSVN？ 1.2. TortoiseSVN 的历史 1.3. TortoiseSVN 的特性 1.4. 安装 TortoiseSVN 1.4.1. 系统要求 1.4.2. 安装 1.4.3. 语言包 1.4.4. 拼写检查器 2. Basic Version-Control Concepts 2.1. 版本库 2.2. 版本模型 2.2.1. 文件共享的问题 2.2.2. 锁定-修改-解锁 方案 2.2.3. 复制-修改-合并 方案 2.2.4. Subversion 怎么做？ 2.3. Subversion 实战 2.3.1. 工作副本 2.3.2. 版本库的 URL 2.3.3. 修订版本 2.3.4. 工作副本怎样跟踪版本库 2.4. 摘要 3. 版本库 3.1. 创建版本库 3.1.1. 使用命令行工具创建版本库 3.1.2. 使用 TortoiseSVN 创建版本库 3.1.3. 本地访问版本库 3.1.4. 访问网络共享磁盘上的版本库 3.1.5. 版本库布局 3.2. 版本库备份 3.3. 服务器端钩子脚本 3.4. 检出链接 3.5. Accessing the Repository 3.6. 基于 svnserve 的服务器 3.6.1. 简介 3.6.2. 安装 svnserve 3.6.3. 运行 svnserve 3.6.3.1. 以服务形式运行 svnserve 3.6.4. svnserve 与基本认证 3.6.5. 使用 SASL 以便更安全 3.6.5.1. 什么是 SASL？ 3.6.5.2. SASL 认证 3.6.5.3. SASL 加密 3.6.6. 使用 svn+ssh 认证 3.6.7. svnserve 基于路径的授权 3.7. 基于 Apache 的服务器 3.7.1. 简介 3.7.2. 安装 Apache 3.7.3. 安装 Subversion 3.7.4. 配置 3.7.5. 多版本库 3.7.6. 路径为基础的授权 3.7.7. 使用 Windows 域认证 3.7.8. 多重认证源 3.7.9. 用 SSL 使服务器更安全 3.7.10. 在虚拟 SSL 主机中使用客户端证书 4. 日常使用指南 4.1. 开始 4.1.1. 图标重载 4.1.2. 右键菜单 4.1.3. 拖放 4.1.4. 常用快捷方式 4.1.5. 认证 4.1.6. 最大化窗口 4.2. 导入数据到版本库 4.2.1. 导入 4.2.2. 导入适当的位置 4.2.3. 专用文件 4.3. 检出工作副本 4.3.1. 检出深度 4.4. 将你的修改提交到版本库 4.4.1. 提交对话框 4.4.2. 修改列表 4.4.3. Excluding Items from the Commit List 4.4.4. 提交日志信息 4.4.5. 提交进程 4.5. 用来自别人的修改更新你的工作副本 4.6. 解决冲突 4.6.1. File Conflicts 4.6.2. Tree Conflicts 4.6.2.1. Local delete, incoming edit upon update 4.6.2.2. Local edit, incoming delete upon update 4.6.2.3. Local delete, incoming delete upon update 4.6.2.4. Local missing, incoming edit upon merge 4.6.2.5. Local edit, incoming delete upon merge 4.6.2.6. Local delete, incoming delete upon merge 4.7. 获得状态信息 4.7.1. 图标重载 4.7.2. 在 Windows 资源管理器中的 TortoiseSVN 列 4.7.3. 本地与远程状态 4.7.4. 查看差别 4.8. 修改列表 4.9. 版本日志对话框 4.9.1. 调用版本日志对话框 4.9.2. 版本日志动作 4.9.3. 获得更多信息 4.9.4. 获取更多的日志信息 4.9.5. 当前工作副本的版本 4.9.6. 合并跟踪特性 4.9.7. 修改日志消息和作者 4.9.8. 过滤日志信息 4.9.9. 统计信息 4.9.9.1. 统计页 4.9.9.2. 作者提交次数统计页 4.9.9.3. 按日期提交统计页 4.9.10. 离线方式 4.9.11. 刷新视图 4.10. 查看差异 4.10.1. 文件差异 4.10.2. 行结束符和空白选项 4.10.3. 比较文件夹 4.10.4. 使用 TortoiseIDiff 进行比较的图像 4.10.5. 其他的比较/合并工具 4.11. 添加新文件和目录 4.12. Copying/Moving/Renaming Files and Folders 4.13. 忽略文件和目录 4.13.1. 忽略列表中的模式匹配 4.14. 删除、移动和改名 4.14.1. 正在删除文件/文件夹 4.14.2. 移动文件和文件夹 4.14.3. 改变文件名称大小写 4.14.4. 处理文件名称大小写冲突 4.14.5. 修复文件改名 4.14.6. 删除未版本控制的文件 4.15. 撤消更改 4.16. 清理 4.17. 项目设置 4.17.1. Subversion 属性 4.17.1.1. svn:keywords 4.17.1.2. 增加和编辑属性 4.17.1.3. Exporting and Importing Properties 4.17.1.4. 二进制属性 4.17.1.5. 自动属性设置 4.17.2. TortoiseSVN 项目属性 4.18. External Items 4.18.1. External Folders 4.18.2. External Files 4.19. 分支/标记 4.19.1. 创建一个分支或标记 4.19.2. 检出或者切换 4.20. 正在合并 4.20.1. 合并指定版本范围 4.20.2. 复兴分支 4.20.3. 合并两个不同的目录树 4.20.4. 合并选项 4.20.5. 预览合并结果 4.20.6. 合并跟踪 4.20.7. 子合并期间处理冲突 4.20.8. Merge a Completed Branch 4.20.9. Feature Branch Maintenance 4.21. 锁 4.21.1. 锁定在Subverion中是如何工作的 4.21.2. 取得锁定 4.21.3. 释放锁定 4.21.4. 检查锁定状态 4.21.5. 让非锁定的文件变成只读 4.21.6. 锁定钩子脚本 4.22. 创建并应用补丁 4.22.1. 创建一个补丁文件 4.22.2. 应用一个补丁文件 4.23. 谁修改了哪一行？ 4.23.1. 追溯文件 4.23.2. 追溯不同点 4.24. 版本库浏览器 4.25. 版本分支图 4.25.1. 版本图节点 4.25.2. Changing the View 4.25.3. 使用图 4.25.4. 刷新视图 4.25.5. Pruning Trees 4.26. 导出一个Subversion工作副本 4.26.1. 从版本控制里移除删除工作副本 4.27. 重新定位工作副本 4.28. 与 BUG 跟踪系统/问题跟踪集成 4.28.1. Adding Issue Numbers to Log Messages 4.28.1.1. Issue Number in Text Box 4.28.1.2. Issue Numbers Using Regular Expressions 4.28.2. Getting Information from the Issue Tracker 4.29. 与基于 WEB 的版本库浏览器集成 4.30. TortoiseSVN的设置 4.30.1. 常规设置 4.30.1.1. 右键菜单配置 4.30.1.2. TSVN对话框设置一 4.30.1.3. TSVN对话框设置二 4.30.1.4. TortoiseSVN 颜色设置 4.30.2. Revision Graph Settings 4.30.2.1. Revision Graph Colors 4.30.3. 图标叠加设置 4.30.3.1. 图标集选择 4.30.4. 网络设置 4.30.5. 外部程序设置 4.30.5.1. 差异查看器 4.30.5.2. 合并工具 4.30.5.3. 差异查看/合并工具的高级设置 4.30.5.4. 统一的差异查看器 4.30.6. 已保存数据的设置 4.30.7. 日志缓存 4.30.7.1. Cached Repositories 4.30.7.2. 日志缓存统计 4.30.8. 客户端钩子脚本 4.30.8.1. Issue Tracker Integration 4.30.9. TortoiseBlame 的设置 4.30.10. 注册表设置 4.30.11. Subversion 的工作文件夹 4.31. 最后步骤 5. SubWCRev 程序 5.1. SubWCRev 命令行 5.2. 关键字替换 5.3. 关键字例子 5.4. COM 接口 A. 常见问题(FAQ) B. 如何实现 … B.1. 一次移动或复制多个文件 B.2. 强制用户写日志 B.2.1. 服务器端的钩子脚本(Hook-script) B.2.2. 工程(Project)属性 B.3. 从版本库里更新选定的文件到本地 B.4. Roll back (Undo) revisions in the repository B.4.1. 使用版本日志对话框 B.4.2. 使用合并对话框 B.4.3. 使用 svndumpfilter B.5. Compare two revisions of a file or folder B.6. 包含一个普通的子项目 B.6.1. 使用 svn:externals B.6.2. 使用嵌套工作副本 B.6.3. 使用相对位置 B.7. 创建到版本库的快捷方式 B.8. 忽略已经版本控制的文件 B.9. 从工作副本删除版本信息 B.10. 删除工作副本 C. Useful Tips For Administrators C.1. 通过组策略部署 TortoiseSVN C.2. 重定向升级检查 C.3. 设置 SVN_ASP_DOT_NET_HACK 环境变量 C.4. 禁用上下文菜单 D. TortoiseSVN 操作 D.1. TortoiseSVN 命令 D.2. TortoiseIDiff 命令 E. 命令行交叉索引 E.1. 约定和基本规则 E.2. TortoiseSVN 命令 E.2.1. 检出 E.2.2. 更新 E.2.3. 更新到版本 E.2.4. 提交 E.2.5. 差异 E.2.6. 显示日志 E.2.7. 检查所作的修改 E.2.8. 版本图 E.2.9. 版本库浏览器 E.2.10. 编辑冲突 E.2.11. 已解决 E.2.12. 改名 E.2.13. 删除 E.2.14. 恢复 E.2.15. 清理 E.2.16. 获得锁 E.2.17. 释放锁 E.2.18. 分支/标记 E.2.19. 切换 E.2.20. 合并 E.2.21. 输出 E.2.22. 重新定位 E.2.23. 在当前位置创建版本库 E.2.24. 添加 E.2.25. 导入 E.2.26. 追溯 E.2.27. 加入忽略列表 E.2.28. 创建补丁 E.2.29. 应用补丁(Apply Patch) F. 实现细节 F.1. 图标重载 G. 用 SSH 使服务器更安全 G.1. 配置 Linux 服务器 G.2. 配置 Windows 服务器 G.3. 用于 TortoiseSVN 的 SSH 客户端工具 G.4. 创建 OpenSSH 证书 G.4.1. 使用 ssh-keygen 创建密钥 G.4.2. 使用 PuTTYgen 创建密钥 G.5. 使用 PuTTY 测试 G.6. 使用 TortoiseSVN 测试 SSH G.7. SSH 配置参数 6. IBugtraqProvider interface 6.1. The IBugtraqProvider interface 6.2. The IBugtraqProvider2 interface
SVN项目文件夹结构指南(附所有目录结构一键生成)
11-11
SVN项目文件夹结构指南，把里面的createdoc.txt改名为createdoc.bat后在windows下运行，所有目录结构自动生成在当前目录下，各企业的项目根据实际情况来修改，本目录适合中小型企业。
SVN的标准目录结构：trunk、branches、tags
05-24
SVN的标准目录结构：trunk、branches、tags
常用项目SVN目录结构
04-21
NULL 博文链接：https://stranger2008.iteye.com/blog/1923805
svn 改动内容备份工具
09-28
vss做版本管理时，新开一个分支有多么不方便，我听很多人吐槽过了，自己也深有体会。 当我在项目中修改代码时，有优先级更高的新的工作要做，需要暂时挂起当前的修改。最好的做法是：新建一个分支，保存当前的修改，再把项目更新到版本库中最新版本。这是我用git做版本管理时最常用的做法，但是用svn却不是很好，首先，svn做一个分支太难了；其次，我需要用一些中间代码在版本库中做一个大家都可以看到的分支，这太ugly了。 基于上述原因，我写了一个脚本，它可以备份当前项目相对svn的改动内容。 这样每次挂起时，我只要执行一个命令就可以了，恢复时使用比较工具，也可以很快的恢复。 这个工具的功能点及优点： 1. 保留项目文件夹结构； 2. 生成diff.txt用于保存所有的改动文件；
【svn目录结构-详细版】-项目管理-svn目录结构-详细版
03-01 3039
上篇文章介绍了SVN目录结构-简单版，今天补充写个详细版，参考学习老东家C-P-I-C的： 01-项目管理文档，包含项目计划、风险管理等 02-项目实施文档，包含需求、设计、测试、使用手册等 04-发布上线，包含每个版本的详细输出，有程序包、脚本文件等 ...
SVN经典目录结构说明
qq_45237335的博客
06-20 3296
svn
SVN的目录结构介绍和版本管理方式
weixin_42216205的博客
04-10 7384
1 SVN标准目录 Subversion有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是： 这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。 trunk：主干，如果说把一个软件...
2-svn的目录结构
网络安全
04-17 2813
1. SVN的安装目录 安装完成后，我们需要了解SVN的每个目录的作用。 bin目录 bin目录下放的都是关于svn的使用命令，比如刚才我们用的svnadmin命令也放在bin目录下。 iconv目录 iconv目录放的都是一些关于国际化的文件，也就是一些编码文件，比如我们熟悉的gb2312编码等都放在此文件夹里，那么何谓国际化？ 所谓软件国际化就是软件开发时，要使它能同时应对...
SVN 项目的目录结构
hongye
03-03 386
一个 SVN 项目的良好目录结构如下： project1 trunk branches tags  1. project1 项目名。 2. trunk 主干目录，用于主干产品的维护。大部分操作都在此目录下完成。 3. branches 分支目录，用于分支产品的维护。 分支目录通过 trunk 的“右键菜单 -&gt; Tortoi...
项目架构SVN
11-08
SVN的介绍 有需要的可以看看，也许有帮助啊
oml:从SVN导入
03-07
oml（对象矩阵库） 这是一个有点过时的C ++矩阵类，它支持所有常用的东西： 矩阵和向量类动态内存分配。 Fortran下标，因此我们可以轻松地将矩阵和向量传递给FORTRAN代码（lapack，arpack等）。 浅复制和写写复制时复制，因此按值传递矩阵既便宜又安全。 各种重叠运算符的表达式模板。 结果，大多数代码都在标头中。 ASCII和二进制IO。 一些线性代数SVD，求解A * x = B，本征系统。 两个和四个抽头XOR随机数生成器。 堆和壳排序。 它在1990年代用于C ++编码的电子结构，蒙特卡洛和电化学模拟。 因此，它使用C ++98。可以使用现代C ++大大简化表达式模板，但是现在可能有更好的矩阵类可用。 我仍然使用它只是因为我知道它是如何工作的并且它以接近机器速度的速度运行。 我目前正在使用它来学习用于求解一维量子自旋系统的矩阵乘积状态。 单元测
常见项目svn目录结构
12-07
常见项目svn目录结构
svn目录使用规范.doc
04-13
介绍SVN各个目录使用规范 Svn目录使用规范 TortoiseSVN客户端工具 选择创建SVN目录结构的选项（生成trunk、branches、tags目录）,如下图： 1、 trunk是主分支，是日常开发进行的地方。 2、branches是分支。一些阶段性的release版本，这些版本是可以继续进行开发和维护的，则放在branches目录中。 3、tags目录一般是只读的，这里存储阶段性的发布版本，只是作为一个里程碑的版本进行存档。 注：在这需要说明下分三个目录的原因，如果项目分为一期、二期、三期等，那么一期上线时的稳定版本就应该在一期完成时将代码copy到branches上，这样二期开发的代码就对一期的代码没有影响，如新增的模块就不会部署到生产环境上。而branches上的稳定的版本就是发布到生产环境上的代码，如果用户使用的过程中发现有bug，则只要在branches上修改该bug，修改完bug后再编译branches上最新的代码发布到生产环境即可。tags的作用是将在branches上修改的bug的代码合并到trunk上时创建个版本标识 Trunk目录：Doc(文档库，放项目相关文档类)、sourcecede（代码库） Doc目录下按项目存放文档，以下以proj1为例做说明 Proj1----项目名 1、Controlled------组织级scm建一个名为controlled的目录，当项目某文档通过评审后，组织级scm从项目目录下找到那文档，复制到controlled目录下。（一般用不到） 2、Develop---开发文档 2.1、Design----设计文档 2.1.1、DbDesign---数据库设计文档 2.1.2、HLD---概要设计 2.1.3、InterfaceDesign---接口设计 2.1.4、ServiceDesign---服务设计 2.2、REQ---需求文档 2.3、SRS---软件需求规格说明 2.4、Test---测试文档 2.4.1、Review---可空 2.4.2、TestCese---测试用例 2.4.3、TestDoc---测试文档 2.4.4、TestEnv---测试环境说明 2.4.5、TestReport---测试报告 3、Document---项目文档 4、Management---管理文档 4.1、Meetings--会议纪要 4.2、PIM--- 4.3、Plan---计划 4.3.1、review 4.3.2、SDP---软件开发策划文档 4.3.3、SPP---软件项目策划文档 4.4、report---报告 4.4.1、Milestonereport---版本报告 4.4.2、ProjectTrackReport---项目跟踪报告 4..4.3、SCM---软件配置管理文档  4.4.4、SQA---软件质量保证计划 4.4.5、项目周报 4.5、Sow---工作说明书 4.6、Summarize---总结 4.7、Template---模板 4.8、Trainning---培训文档 打标签/分支有两种方式： 1、选中项目，就是trunk下的本地项目，右击，选中Branch/Tag，出现如下对话框。 下图中的配置完成了之后，点击OK即可完成“打标签/分支”。 2、直接在SVN上在对应的标签/分支目录下创建对应的版本文件夹，将trunk下稳定版本的代码直接copy到对应的文件目录下即可。
Git和SVN有什么区别?
zhangjiaming_zjm的博客
04-24 438
Git可以轻松地创建、合并、删除分支，支持多个分支并行开发，并提供了一些高级分支管理工具，如rebase、cherry-pick等。Git和SVN在内部实现上也存在差异。，每个开发者本地都有一份完整的代码仓库，可以离线工作、本地提交、本地回滚等操作，不依赖于中央服务器。Git可以处理非常大的代码仓库，因为每个开发者都有一份完整的仓库，不需要集中式仓库的所有数据。Git和SVN都是版本控制系统，它们都是用来帮助团队协同开发，管理代码版本的。但是，git和svn在实现方式，使用方法，特性等方面都存在一些差异。
SVN--基本原理与使用（超详细）
sushang的博客
04-27 955
1.为什么需要SVN版本控制软件我们想开发一个系统，需要张三，李四、王五三个人进行开发，每个人开发一个系统的某几个模块，我们称作协作开发。他们开发之间进行交流称作远程开发。最后合并成几个版本，如v1.0 、v2.0。这时候就需要SVN来进行版本管理，主要是三个功能：版本回退，协作开发，远程开发。2.解决之道SCM：（Software configuration management）软件配置管理，所谓的软件配置管理实际就是对软件源代码进行控制与管理CVS：元老级产品VSS：入门级产品。
windows上通过定时任务提交新增文件到SVN（bat双击可执行，但是通过定时任务后无法提交到svn）
起早贪黑写bug
04-28 327
bat双击可以运行，定时任务无法运行。通过定时任务自动提交文件至SVN
后端开发是一个涉及广泛技术和工具的领域.docx
最新发布
04-30
后端开发是一个涉及广泛技术和工具的领域，这些资源对于构建健壮、可扩展和高效的Web应用程序至关重要。以下是对后端开发资源的简要介绍： 首先，掌握一门或多门编程语言是后端开发的基础。Java、Python和Node.js是其中最受欢迎的几种。Java以其跨平台性和丰富的库而著名，Python则因其简洁的语法和广泛的应用领域而备受欢迎。Node.js则通过其基于JavaScript的单线程异步I/O模型，为Web开发提供了高性能的解决方案。 其次，数据库技术是后端开发中不可或缺的一部分。关系型数据库（如MySQL、PostgreSQL）和非关系型数据库（如MongoDB、Redis）各有其特点和应用场景。关系型数据库适合存储结构化数据，而非关系型数据库则更适合处理大量非结构化数据。 此外，Web开发框架也是后端开发的重要资源。例如，Express是一个基于Node.js的Web应用开发框架，它提供了丰富的API和中间件支持，使得开发人员能够快速地构建Web应用程序。Django则是一个用Python编写的Web应用框架，它采用了MVC的软件设计模式，使得代码结构更加清晰和易于维护。
华为数字化转型实践28个精华问答glkm.pptx
04-30
华为数字化转型实践28个精华问答glkm.pptx
svn项目版本管理标准规范
07-27
SVN是一种常用的版本控制工具，用于管理软件开发项目中的代码版本。为了保证多人协作开发项目时的代码一致性和易于追踪，需要制定一些标准规范。 首先，需要确定代码库的组织结构。可以按照项目的模块或功能进行分支，每个分支对应一个子目录，使得不同功能的代码能够分开管理。 其次，要设定分支策略。可以使用主干（trunk）、开发分支（branches）和发布分支（tags）的结构。主干用来存放稳定发行版本的代码，开发分支用于不同功能的开发和测试，发布分支用于标记发布的版本。 在提交代码时，要求开发者填写有意义的注释。注释应该简明扼要地描述修改的内容，以便其他人可以轻松理解代码的更改和目的。 并行开发时，避免频繁合并代码，可以采用定期的集成策略。每隔一段时间，进行一次代码的整合和合并，确保各个分支的代码同步。 在管理代码权限时，要进行适当的权限控制。只让必要的人员具有修改代码的权限，其他人员只具有查看和下载的权限。 对于项目中的重要决策和问题，可以使用SVN的问题追踪和讨论功能，让开发者能够方便地记录和解决问题。 另外，在使用SVN时，要定期备份代码仓库以确保数据的安全性。 总之，通过制定SVN项目版本管理的标准规范，可以提高多人协作开发的效率和质量，保证项目代码的稳定性和可追溯性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值