所以,你不会听到我说svn和git不是非常强大和多功能的工具,但对于非本地开发(中央网络共享)它并不能很好地发挥作用(两个人实际上可以在同一个文件上工作)并产生相当大的开销,所以具体地说我想知道是否有任何替代方案可以很好地处理中央网络共享(主要使用的功能是责备并确定稳定的代码和开发码)。
我知道这是一个相当广泛的问题,我希望这属于Stackoverflow的范围,但是由于类似的问题没有关闭,我决定给这个问题一个。
在反应过程中似乎存在一种常见的误解:现在我们正在使用颠覆,我们正在进行更改,我们使用标签来区分版本并仅将标记的更改推送到生产中。此外,似乎相信本地副本在某种程度上是协作发展的圣杯。让我告诉你,如果你在任何时候只与同一个项目的4个开发人员一起工作,那么理想的是你可以使用相同的文件,前提是你没有使用一些古老的低级语言,这需要汇编所有文件。代码和单个语法错误打破了整个应用程序。确实如此,偶尔也会造成不必要的错误,但总的来说它的效果非常好并且有助于加快开发速度。 实际的主要问题在于,如果不同的人提交并处理相同的svn checkout,svn往往会破坏很多。此外还有一些其他事情往往会造成麻烦(而且svn似乎不会像坐在共享上那样,虽然其中一个答案可能有助于“修复”),但事实是所有这些都是由于SVN和GIT都是基于个人开发人员在他们自己的本地副本上工作的想法而导致的,这与我们正在进行的共享代码库上的紧密编织开发风格不相符。
在谈到这一点后,我们得出结论,我们可以想象一个更简单,不那么先进的源控制系统更适合这种开发风格(例如,用户使用谷歌驱动器的体验等全自动修订跟踪系统文档+附加某种形式的标记文件)我们认为其他人也必须考虑到这个以及这个问题的来源。如果您认为我们的开发风格不好,请允许我指出我们公司目前能够达到与我们竞争的类似大型Web应用程序开发公司一样高3-5倍的效率(以及不选择增长的选择)是有意识的一个)并且,是的,这个设置是帮助实现这种效率的原因之一,因为无论流行的版本控制系统有多漂亮:它们都会增加很多的开销。正如我在下面的一条评论中所说,对我们来说,设置本地开发环境意味着必须设置大约50x4 = 200个不同的开发应用程序才能运行。这意味着在每个开发系统上有3个不同的IIS实例(由于我们正在使用的插件的限制以及这个'插件的3个不同版本的必要性) ,一个apache / tomcat实例和一个apache / jetty实例。另外,对于每个开发人员,这5个实例分为50个应用程序的不同子集。 (我甚至不想考虑如何让这5个实例一起运行以及如何处理跨应用程序请求)将所有这些与当前设置进行比较,我们只需要每个应用程序的三个不同实例(开发,分期和生产)它根本就没有道理。而且我甚至没有提到公司中只有大约2或3个人知道如何设置这些实例......顺便说一下(对于新项目我们已经从这个烂摊子中迁移出来了,但对于所有人来说那些仍然支持的旧项目是无关紧要的。)
我试图尽可能地使这个问题变得通用,以防止它只适用于我们,但是某些人在一些答案和评论中给出的那种反应只是令人难以置信的傲慢。老实说,我们已经考虑过这一点,我问了一个相当具体的问题。如果问题是要求svn / git的替代方案,它就是如此放肆地给出答案:"使用svn" /"使用git"或者"这个问题让我哭了#34;并没有冒犯@David W.因为与其他人不同,我认识到你诚实地试图提供帮助,但我认真地考虑在看到这些评论后退出stackoverflow。 < /咆哮>
无论哪种方式,我仍然希望有人能够指出一些截然不同的源代码控制方法,但从它的外观来看,情况并非如此。可能有一天我最终会自己写这篇文章,但是现在我没有时间,所以我有点希望其他人已经这样做了。
答案 0 :(得分:1)
如果没有服务器来管理修改,则无法阻止两个人同时修改同一个文件。这就是为什么当你有多个人在一个项目上工作时你不应该在Subversion中使用file://
协议。你永远不应该在网络上使用它。
对于Subversion,您可以使用svnserve
进程在包含共享的系统上创建轻量级服务器。它简单快捷。甚至可以将其设置为Windows服务。完成后,您可以使用svn://
协议,svnserve
进程将规范更改。
Git允许您拥有多个存储库,每个存储库相互拉动和推送更改。实际上,您根本不需要主Git存储库。而且,这就是为什么Git可能是您处理设置的最佳方式。
您和您的同事都可以拥有自己的私人Git存储库。你自己办理入住手续。您通过email互相同步。没有服务器。没有Windows共享。两个人试图同时更改同一个文件没问题。
我使用Dropbox来存储我的Git存储库,因此我可以在家中和工作中使用我的存储库。
Word'o Warning :如果您像这样使用Dropbox,则不能让两个人一次推送到此Dropbox Git存储库。你可以让多个人做拉,但不要推。
但是,我和其他人不共享这个Dropbox Git仓库。这是我的,只有我的。我在工作的电脑上使用它,回家,然后继续在家工作。我使用电子邮件将该存储库与我项目中的其他人同步,如上所述。
答案 1 :(得分:1)
其他答案已经指出,一般来说,同时在一台服务器上工作的多个人可能会有问题。我同意 - 但是,你写道,这对你有用,所以我不会争论。
那就是说,我的版本控制解决方案是:
这样,多人可以在一台服务器上工作。他们只是照常提交,与正好在同一系统上工作的任何同事协调。使用Git可以更容易一些,因为它可以更容易地只提交工作副本中的一部分更改,但它也适用于SVN。
通过合并在系统之间交换代码。如果在“dev”中完成了新功能,则可以将“dev”代码合并为“staging”,然后将“staging”合并为“prod”。标签可用于识别适合合并到下一阶段的版本 - 因此您不会将最新的“dev”合并到“staging”中,而是将“featureX-dev”标记为指向分支上的旧版本“开发”。
如果你使用Git,如果你必须打断你的工作并且正在进行工作,那么本地分支可能会很有用。然后,您可以将正在进行的工作提交到本地临时分支,使工作副本(和主分支)保持清洁,以便其他人可以在同一服务器上工作。当然,这需要暂时检查您的临时分支,因此您需要与在同一系统上工作的任何其他人协调。
答案 2 :(得分:0)
我想知道是否有任何替代品可以在中央网络股票上运作良好
我很害怕,但真正的替代是“改变你懒惰的工作流程和习惯” - 你希望(现在)组合不兼容的东西
“50-100个不同的项目”只有50-100个存储库(位于中心位置)和开发框上的50-100个工作副本(有些工作需要创建它,是的,但它是一次性操作)和< strong> ONE(在DVCS的情况下为两个 - 推送添加)附加操作供开发人员在稍后的开发过程中提交。
替换的“非管理无政府状态”的开销很小,具有明确且易于管理的开发过程和公平价格
答案 3 :(得分:0)
让我告诉你,如果你只与4位开发者合作 同一个项目在任何时候都适合处理相同的文件
烈。即使是围绕单个常见(非常常见作为映射网络驱动器)代码库的2位开发人员,您也不能保证,他们不会同时修改同一个文件并覆盖外来的变化(除了使用古老的“锁定和等待”模型),因此 - 有很多头痛
实际的主要问题在于,如果不同的人在同一个svn结账时提交和工作,svn往往会破坏很多
实际的主要问题是而不是Subversion (如果以正确的方式(tm)使用,它不会破坏任何东西) - 但未经训练的用户,使用显微镜进行钉钉
我们设置本地开发环境意味着必须设置大约50x4 = 200个不同的开发应用程序才能运行
您可以(有)将工作流程更改为正确使用Subversion 而不构建LDE。只需在服务器上添加本地工作区层(其中开发人员编辑个人WC中的代码)和提交后挂钩以更新服务器开发环境(并且可能在提交之前更新+合并时开始使用分支)过时的WC /会惹恼开发者)
我们可以想象一个更简单的不太先进的源控制系统更适合这种开发风格
嗯,这是WebDAV - 没有任何东西的线性版本控制。对于最终用户,它将是相同的共享驱动器