VSS到Subversion

Mat*_*ttH 3 svn migration visual-sourcesafe

我正在研究从SourceSafe到Subversion的潜在转变,我们正在努力进行编辑/合并/提交与checkout/update/checkin范式.主要关注的是如何知道哪些文件是使用Subversion(以及向谁)签出的?

在VSS中是否存在等同于"状态搜索"的Subversion?或者因为缺乏"保留结账"而无法实现?

另外,如果我们尝试通过"锁"实现Subversion的"保留检查",是否有支持"锁定结账"的GUI(TortoiseSVN,VirtualSVN等)?

谢谢.

更新:例如,在我们进行构建/发布之前,我们希望绝对确保所有文件都已签入.开发人员忘了.所以我们需要知道哪些文件已签出.这可能与Subversion有关吗? 是否可以查看签出(或锁定)文件的列表? 浏览资源管理器中的整个代码库是不可行的,是否有一些报表样式的列表或搜索功能?

T.E*_*.D. 8

如果你正在使用编辑/合并/提交范例(你不需要使用Subversion,顺便说一句),那么实际上没有人会"检出"文件.

使用编辑/合并时,没有文件被锁定,您将假设每个文件都被检出(解锁)给每个用户.

开发人员下拉整个基线(或者至少是他们想要构建的部分),他们只是在情绪受到影响时编辑他们想要的任何内容.当他们想要检查他们的更改时,那就是"合并"的来源.

乍一看,作为VSS用户,您可能会认为签入文件可以"清除"自您检查后对该文件所做的更改.我不明白这最初是如何起作用的.这里的诀窍是,SVN可以判断其他人在检查完该文件的版本时,因此需要将其合并而不是简单地替换.它比VSS更聪明.:-)

理论上说它不应该发生太多,从长远来看,你将花费更少的时间来处理冲突的编辑,而不是花在尝试处理别人锁定的文件上.我做过的一次快速的卫生巾计算表明,在我工作的地方可能是正确的,但是YMMV.


更新:对于您尝试保护开发人员不要忘记检查更改的过程,这可能不再适用.您可以尝试在每个开发人员的工作目录中查找并查找差异,但我认为我们都同意这是不可行的.

锁定模型为开发人员提供了一种方式来声明将文件修改为中央存储库的意图是正确的,而编辑/合并则没有.为一种方法构建的工具通常只是扁平化而对另一种方法毫无意义.这是其中一个案例.

我作为toolmeister的建议是尝试使用SVN的小型(或玩具)项目来熟悉不同的工作方法.一旦你明白了,你应该能够绕过它.

  • @MattH:再说一遍,没有像编辑/合并那样的"锁定".你的问题大致就像坐在直升机驾驶舱内的喷气式飞行员,并开始询问有关推进器的问题. (2认同)

laa*_*lto 8

SVN很乐观:合并冲突很少见且容易解决.VSS是悲观的:合并冲突很难解决,你可以通过锁定避免它们.所以在svn中,你不需要知道文件被"签出"了.您只需签出一个没有锁定的版本并根据需要进行编辑.冲突在提交之前得到解决,并且通常svn会自动为您解析冲突,除非两个或多个提交正在修改相同的源代码行.

因此,实际上不需要"状态搜索".

SVN确实支持锁定的概念,这对于那些难以合并的二进制文件很有用.即使在那里锁也不难; 它只是向其他开发者发出的信号"请不要在我编辑此文件时提交." SVN GUI可以选择锁定文件.您还可以使用特殊svn:needs-lock属性强制执行锁定.

有关锁定的更多信息,请参阅svnbook:http://svnbook.red-bean.com/en/1.2/svn.advanced.locking.html