混合版本控制和同步系统？
有人知道混合版本控制和同步系统吗？
我目前是一个快乐的 Mercurial 用户，但我的项目通常包含混合文件。
其中大部分（代码、文档……）我希望进行版本控制。这就是我使用 Mercurial 的原因。
但是，在极少数情况下，我希望在工作副本之间同步文件，但不进行版本控制。
例如，我对我编写的用于图像处理的代码进行版本控制。这段代码可以生成一大堆输出图像，我希望这些图像能够同步，这样我就不必记住在我的各种计算机上随机播放它们，但是控制这些版本是没有意义的。
澄清一下 - 我知道 Mercurial 的扩展，例如 bfiles 和 bigfiles，这对于我的图像示例来说很方便，但我只是想知道是否有人知道处理此问题的替代方法。我只想要一个可以告诉我“对除那些应该同步但没有历史记录的文件之外的所有文件进行版本控制”的系统。
干杯！
编辑：我可以执行类似添加 hg marksync 的操作，将 hg Push/hg pull 添加一个钩子，该钩子将在后台运行 rsync （或任何同步工具），但我想知道是否有一个不那么老套的解决方案（我认为 bfiles/bigfiles 无论如何都会按照这些思路做一些事情）。
Is anyone aware of a hybrid version control and synchronising system?
I'm currently a happy mercurial user, but my projects usually contain a mixture of files.
Most of these (code, documentation, ...) I want to be version-controlled. This is why I use mercurial.
However, on the rare occasion I have files that I would like to synchronise between my working copies, but not version control.
For example, I version control the code I write to do image processing. This code can produce a whole bunch of output images which I'd like to have synchronised so I don't have to remember to shuffle them around my various computers, but there's no point having these version controlled.
To clarify - I am aware of extension to mercurial such as bfiles and bigfiles, which are handy for my image example, but I was just wondering if anyone out there knows of alternative ways to handle this. I just want the one system that I can tell "version control all files except those ones, which should be synced but have no history".
cheers!
EDIT: I could do something like adding a hg marksync <filename> that added <filename> to a list of files to be synced, and then adding a hook to hg push/hg pull that would (say) run rsync (or whichever sync tool) in the background, but I wondered if there was a less hacky solution (I think bfiles/bigfiles do something along these lines anyway).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
版本控制系统（任何）不关心
的同步如果您想同步任何文件 - 使用专门为此任务设计的工具：fersync
Version Control System (any) doesn't care about synchronization of
If you want sync any files - use specially designed for this task tools: f.e. rsync
这是数据还是您代码的一部分？
如果数据：远离版本控制系统，就不要去那里。如果它是代码的一部分（如布局图像），请将其签入。这些是唯一被普遍接受的方法。
数据的一个很好的解决方案是同步或生成它们。因此，您可以在部署到服务器后添加一个步骤：GenerateImages()。
编辑：除了线程发起者所做的评论之外：
如果图像是数据并且您需要在不同的系统上处理它们，请不要考虑代码的版本控制。这是无关的。按照处理顺序，对我来说有意义的步骤：
从更新图像代码开始，在版本控制中检查它。然后将更新的代码部署（是的，这就是部署）到处理计算机。现在代码已经完成了。
然后你就有数字处理程序应该处理的任务。就像处理图像一样。因此，从处理程序本身（可能有一些队列发生在那里）或从中央调度程序开始处理。
然后您就可以在本地计算机上获得结果。现在必须对这些数据进行处理，因此这也是您软件的一部分。决定是否希望处理程序将它们发送到某个中央存储、您的工作站或其他位置。让软件来处理吧。这是我阅读你的问题时最难的部分。许多解决方案都是可能的，从 FTP/网络传输到特定的存储解决方案。愿意提供帮助，但需要有关这些零件的实际问题、数量、尺寸等的更多信息。
如果图像处理器的新更新版本使旧生成的图像过时，请在您的代码中实现这一点，例如通过将属性附加到生成的文件、单独的文件夹或其他指示。这样您就可以在更新后请求处理程序重新生成任何过时的文件。
Is this DATA or part of your CODE?
If data: Keep out of your versioning system, just don't go there. If it is part of your code (like layout images) check it in. Those are the only ways which are the generally accepted.
A nice solution for the data would be syncing OR generating them. So you might add a step after deployment to a server: GenerateImages().
edit: In addition to the comment made by the thread starter:
If the images are data and you need to process them on a different system don't think about the version control for your code. It is unrelated. The steps which would make sense to me, in order of processing:
Start with updating your image code, check it in versioning. Then deploy (yes this is deployment) the updated code to the cruncher computer. Now code is done.
Then you have tasks which the number cruncher should handle. Like processing the images. So start that processing from either the cruncher itself (probably some queue happens there) or from a central dispatcher.
Then you have the results locally at the cruncher. Now something has to happen with that data, so that's also part of your software. Decide whether you want the cruncher to send them to some central storage, your workstation or another location. Let the software handle that. This is the most hard part as I read through your question. Many solutions are possible from just FTP/network transfers to specific storage solutions. Willing to help but need more info about the real issues, amounts, sizes etc. on these parts.
If the new updated version of the image processor makes the old generated images obsolete implement that also in your code, by for example attaching an attribute to the files generated, a seperate folder or another indication. That way you could request the cruncher after update to re-generate any obsolete files.