I'm not even sure programmers can realistically cope with distributed version control. For proof, I offer the number of distributed version control questions on Stack Overflow.
My suggestion would be to give the artists two checklists or cheat sheets. One to commit art work, and one to retrieve art work. These cheat sheets would be specific to your work environment.
If an artist wants to understand the what of source control, one of the programmers can explain the details.
It's been my experience that most people want to get their work done, and don't care about the what. They just care about how.
With Mercurial, you have the option of letting the artists continue with Subversion, while letting the developers switch to Mercurial and thus enjoy the benefits of distributed revision control.
The trick is to use a Subversion subrepository in Mercurial. Mercurial lets you nest repositories: Mercurial 1.7 has support for Mercurial and Subversion subrepositories, Mercurial 1.8 will have support for Git subrepositories.
You control a subrepo via a file called .hgsub. In your case you would add something like this to the file:
This instructs Mercurial to make a svn checkout of http://svn.example.org/graphics/rendered and to store the checkout as graphics/rendered in your Mercurial working copy. In other words, the format of the .hgsub file is
mount-point = [type]source-URL
You make the first checkout yourself, add the .hgsub file and make a Mercurial commit. At that point, Mercurial will take note of the precise Subversion revision that is checked out in your subrepo. This revision number is stored in .hgsubstate, which is an extra file tracked by Mercurial.
When another developer makes a clone of the Mercurial repository, Mercurial will notice the .hgsub and .hgsubstate files, and use them to recreate the Subversion checkout you committed.
The advantages of this solution are:
the artists can continue working with Subversion. Here I'm simplifying things a bit by assuming that they can work with their graphics files in isolation without cloning the outer Mercurial repository. Even if that is not true, then they can still do the majority of their work using Subversion and only do hg pull --update once in a while to get the latest Mercurial changes.
developers wont have to download all revisions of all graphics files. This is normally a show-stopper for (any) distributed revision control system when talking about large binary files.
The problem is that with centralized revision control, it is only the server that needs to store all revisions of a given file, but with distributed revision control every developer stored every version.
Externalizing the binary assets into a Subversion subrepo side-steps this issue.
Mercurial is all about revision control and about giving you consistent snapshots of the project. Mercurial will therefore only checkout things that were explicitly committed. This means that the developers will have to regularly pull in new Subversion revisions:
$ cd graphics/rendered
$ svn update
$ cd ../..
$ # test new graphics!
$ hg commit -m 'Updated graphics'
The Mercurial commit is committing the new Subversion revision number in the .hgsubstate file -- Mercurial will take care of inserting the number in the file, the developers just have to commit it. This way, each Mercurial changeset will reference a particular Subversion revision via the .hgsubstate file, and so you can recreate any past state (consisting of source code and graphics) accurately.
Git exposes a more detailed model, which is liked by many programmers. Mercurial provides a more clean and smaller subset of concepts to deal with. I believe Mercurial will be more suitable for your purpose.
i might be a bit late to the party (and hopefully not off topic), but in your original post you mentioned:
"Keep in mind that using something like Perforce, regardless of how suited it might be for the job, is not option for a free of charge open source project."
if you are really interested in Perforce you might be interested to know:
"If you develop software that is licensed or otherwise distributed exclusively under an Open Source license, you may be eligible to obtain a Perforce license free of charge. This includes upgrades but does not include Technical Support." -- http://www.perforce.com/perforce/price.html
It sounds to me like you're having a hard enough time getting the artists to use SVN and pushing DVCS on them would be a losing battle. Perhaps there's a way to update the DVCS with SVN checkins so that the DVCS can stay up-to-date with SVN?
Regarding adoption of SVN, I think it really catches on for people with they see it as something they need (or can't live without), rather than something 'the man' is forcing them to do. If they could see how they can benefit from the tool (ie, rolling back to previous revisions, etc), they may be more eager to adopt it. However, I don't know if SVN can benefit an artist the way it does a programmer.
As a programmer who's developed both with and without VCS, I can honestly say the VCS world is a much better place, and I will never go back to a world without.
发布评论
评论（6）
我什至不确定程序员能否真正应对分布式版本控制。为了证明这一点，我在 Stack Overflow 上提供了分布式版本控制问题的数量。
我的建议是给艺术家两张清单或备忘单。一种是提交艺术作品，另一种是回收艺术作品。这些备忘单将特定于您的工作环境。
如果一位艺术家想要了解源代码控制的含义，其中一位程序员可以解释详细信息。
根据我的经验，大多数人都想完成他们的工作，而不关心做什么。他们只关心如何。
I'm not even sure programmers can realistically cope with distributed version control. For proof, I offer the number of distributed version control questions on Stack Overflow.
My suggestion would be to give the artists two checklists or cheat sheets. One to commit art work, and one to retrieve art work. These cheat sheets would be specific to your work environment.
If an artist wants to understand the what of source control, one of the programmers can explain the details.
It's been my experience that most people want to get their work done, and don't care about the what. They just care about how.
借助 Mercurial，您可以选择让艺术家继续使用 Subversion，同时让开发人员切换到 Mercurial，从而享受分布式版本控制的好处。
诀窍是在 Mercurial 中使用 Subversion 子存储库。 Mercurial 允许您嵌套存储库：Mercurial 1.7 支持 Mercurial 和 Subversion 子存储库，Mercurial 1.8 将支持 Git 子存储库。
您可以通过名为
.hgsub的文件控制子存储库。在您的情况下，您可以在文件中添加如下内容：这指示 Mercurial 对
http://svn.example.org/graphics/rendered进行svn checkout并将结账存储为 Mercurial 工作副本中的graphics/rendered。换句话说，.hgsub文件的格式是您自己进行第一次签出，添加
.hgsub文件并进行 Mercurial 提交。此时，Mercurial 将记录在您的子存储库中签出的精确 Subversion 版本。此修订号存储在.hgsubstate中，这是 Mercurial 跟踪的额外文件。当其他开发人员克隆 Mercurial 存储库时，Mercurial 会注意到
.hgsub和.hgsubstate文件，并使用它们重新创建您提交的 Subversion 签出。该解决方案的优点是：
艺术家可以继续使用 Subversion 进行工作。在这里，我稍微简化了一些事情，假设他们可以单独使用图形文件，而无需克隆外部 Mercurial 存储库。即使情况并非如此，他们仍然可以使用 Subversion 完成大部分工作，并且只需偶尔执行一次
hg pull --update即可获取最新的 Mercurial 更改。开发人员不必下载所有图形文件的所有修订版。当谈论大型二进制文件时，这通常是（任何）分布式版本控制系统的一个障碍。
问题在于，使用集中式版本控制时，只有服务器需要存储给定文件的所有版本，但使用分布式版本控制时，每个开发人员都存储每个版本。
将二进制资源外部化到 Subversion 子存储库中可以避免此问题。
Mercurial 的核心是版本控制以及为您提供一致的项目快照。因此，Mercurial 只会检查明确提交的内容。这意味着开发人员必须定期引入新的 Subversion 修订版：
Mercurial 提交正在
.hgsubstate文件中提交新的 Subversion 修订版号 - Mercurial 将负责在文件中插入该编号，开发人员只需提交即可。这样，每个 Mercurial 变更集都将通过.hgsubstate文件引用特定的 Subversion 修订版，因此您可以准确地重新创建任何过去的状态（由源代码和图形组成）。With Mercurial, you have the option of letting the artists continue with Subversion, while letting the developers switch to Mercurial and thus enjoy the benefits of distributed revision control.
The trick is to use a Subversion subrepository in Mercurial. Mercurial lets you nest repositories: Mercurial 1.7 has support for Mercurial and Subversion subrepositories, Mercurial 1.8 will have support for Git subrepositories.
You control a subrepo via a file called
.hgsub. In your case you would add something like this to the file:This instructs Mercurial to make a
svn checkoutofhttp://svn.example.org/graphics/renderedand to store the checkout asgraphics/renderedin your Mercurial working copy. In other words, the format of the.hgsubfile isYou make the first checkout yourself, add the
.hgsubfile and make a Mercurial commit. At that point, Mercurial will take note of the precise Subversion revision that is checked out in your subrepo. This revision number is stored in.hgsubstate, which is an extra file tracked by Mercurial.When another developer makes a clone of the Mercurial repository, Mercurial will notice the
.hgsuband.hgsubstatefiles, and use them to recreate the Subversion checkout you committed.The advantages of this solution are:
the artists can continue working with Subversion. Here I'm simplifying things a bit by assuming that they can work with their graphics files in isolation without cloning the outer Mercurial repository. Even if that is not true, then they can still do the majority of their work using Subversion and only do
hg pull --updateonce in a while to get the latest Mercurial changes.developers wont have to download all revisions of all graphics files. This is normally a show-stopper for (any) distributed revision control system when talking about large binary files.
The problem is that with centralized revision control, it is only the server that needs to store all revisions of a given file, but with distributed revision control every developer stored every version.
Externalizing the binary assets into a Subversion subrepo side-steps this issue.
Mercurial is all about revision control and about giving you consistent snapshots of the project. Mercurial will therefore only checkout things that were explicitly committed. This means that the developers will have to regularly pull in new Subversion revisions:
The Mercurial commit is committing the new Subversion revision number in the
.hgsubstatefile -- Mercurial will take care of inserting the number in the file, the developers just have to commit it. This way, each Mercurial changeset will reference a particular Subversion revision via the.hgsubstatefile, and so you can recreate any past state (consisting of source code and graphics) accurately.以下是对版本控制和 Mercurial 的良好直观介绍。
尝试看看是否有助于使其更容易理解。我会发现很难使用一些我无法在脑海中思考的东西。
因此，这里有一些很好的视觉介绍：
Git 公开了更详细的模型，受到许多程序员的喜欢。 Mercurial 提供了更干净、更小的概念子集来处理。我相信 Mercurial 会更适合您的目的。
The following are good visual introduction to version control and Mercurial.
Try to see, if it helps in making it easier to understand. I would find it very difficult to use something, which I can not wrap around in my head.
So here are few good visual introductions:
Git exposes a more detailed model, which is liked by many programmers. Mercurial provides a more clean and smaller subset of concepts to deal with. I believe Mercurial will be more suitable for your purpose.
我们有美术人员使用 GIT 来制作游戏。
对我们来说，SmartGIT 客户端至关重要。
它还具有 SVN 风格。
关联
http://www.syntevo.com/smartgit/index.html
We have Artists working on games with GIT.
For us the SmartGIT client is essential.
It also comes in SVN flavor.
Link
http://www.syntevo.com/smartgit/index.html
我参加聚会可能有点晚了（希望不是偏离主题），但在你原来的帖子中你提到：
如果您真的对 Perforce 感兴趣，您可能有兴趣了解：
i might be a bit late to the party (and hopefully not off topic), but in your original post you mentioned:
if you are really interested in Perforce you might be interested to know:
在我看来，让艺术家使用 SVN 已经够困难的了，而向他们推行 DVCS 将是一场失败的战斗。也许有一种方法可以通过 SVN 签入来更新 DVCS，以便 DVCS 可以与 SVN 保持同步？
关于 SVN 的采用，我认为它确实很受人们欢迎，因为他们认为它是他们需要的东西（或者没有它就活不下去），而不是“男人”强迫他们做的事情。如果他们能够看到如何从该工具中受益（即回滚到以前的修订版等），他们可能会更渴望采用它。然而，我不知道 SVN 是否可以像对程序员那样为艺术家带来好处。
作为一名使用或不使用 VCS 进行开发的程序员，我可以诚实地说，VCS 世界是一个更好的地方，而且我永远不会回到没有 VCS 的世界。
It sounds to me like you're having a hard enough time getting the artists to use SVN and pushing DVCS on them would be a losing battle. Perhaps there's a way to update the DVCS with SVN checkins so that the DVCS can stay up-to-date with SVN?
Regarding adoption of SVN, I think it really catches on for people with they see it as something they need (or can't live without), rather than something 'the man' is forcing them to do. If they could see how they can benefit from the tool (ie, rolling back to previous revisions, etc), they may be more eager to adopt it. However, I don't know if SVN can benefit an artist the way it does a programmer.
As a programmer who's developed both with and without VCS, I can honestly say the VCS world is a much better place, and I will never go back to a world without.