Mar*_*P S 13 git version-control mercurial webdav auto-versioning
我刚刚了解了SVN的WebDAV自动版本控制功能.虽然我知道这不是正确版本控制的替代品,但是消息记录了变更集,它让我感觉像是Dropbox的坚实而安全的替代品(减去漂亮的GUI和网页).但是,由于自动版本控制中的提交很频繁,我认为Git或Hg更适合这种情况,因为它们的数据库更紧凑(尽管我想知道事物的分布式特性是否会使自动化变得难以解决冲突).
据了解,这是一个使用Git或Hg实现的功能吗？
市场上有一个选择这个问题:
WsgiDAV是一个python WebDAV服务器,提供各种后端,包括DVCS mercurial,以及其他一些时尚商店(couchdb,mongodb,MySQL,App Engine).请注意当前版本声称"这不是生产代码".
它似乎与SVN的WebDAV版本不同,自动转换,允许您一次提交由多个更新组成的变更集(通过从"编辑"拖动到"已发布"文件夹等等,而SVN + WebDAV的自动版本创建了太多的提交,创建了因为它不是完全自动版本化,但它不需要命令行访问,并且IMO是一个优秀的模型.
更普遍地考虑这个...我不推荐自动提交WebDAV + SVN的东西.正如你所说,"提交自动版本是很常见的".但它们非常频繁,通常毫无意义.
我自己的解决方案是在我的服务器上运行git或mercurial存储库,并使用cron-job定期对其进行版本更改.丑陋,但功能齐全,不需要特殊的服务器设置/没有特殊的apache模块/等.更好的是,我可以通过WebDAV或SFTP或Windows/apple文件共享或本地DVCS镜像访问所述存储库,具体取决于我的需求,它们都可以无缝地工作.
例如,Git具有相当好的文件移动检测功能,因此减少了对WebDAV访问本身的需求.然而,如果在没有通过将其转换为svn mv命令的访问层的情况下移动SVN结账中的目录,则可能导致可怕的损坏.AFAICT,WebDAV + SVN的主要好处是它可以防止您以这种方式破坏自己的结账.
另一方面,在这种情况下,git或mercurial的"紧凑数据库"并不是优先于SVN的真正理由.但是,如果你正在考虑必须处理真正的同步冲突,我建议他们中的任何一个超过颠覆,因为它们具有出色的冲突解决方案和一般较低的大小/灵活性.
除了 SVN 之外，似乎还没有人为其他 VCS 编写自动版本控制。由于 WebDAV/DeltaV 支持是在 SVN 服务器中实现的，因此不可能将 VCS 切换到 SVN 以外的其他服务器。
几乎所有 DVCS 都可以进行普通 WebDAV 访问，但它们只能访问 WebDAV 客户端的存储库以及 DVCS 自己的客户端的推送操作，但不能进行自动版本控制。
一些链接可了解更多信息：
| 归档时间： |
|
| 查看次数： |
6185 次 |
| 最近记录： |