通过 Eclipse 在 Perforce 中对文件进行少量本地编辑的正确方法是什么？
我在一家使用 Perforce 的公司工作，发现当我出于纯粹本地目的在本地编辑某些内容时（也许我想更改路径以指向本地内容进行测试等），这真的很烦人，更改会自动添加到我的待处理更改列表中，并最终使其变得混乱。直观上，这似乎很奇怪，但实际上却很烦人。这也让其他人看起来像是我正在编辑文件并计划将其上传回仓库，而这根本不是我的本意。综上所述，是否有一种简单的方法来区分我计划提交的编辑和我只想在本地存在的编辑？我正在使用 Perforce 的 eclipse 插件，所以如果有人能给我一种轻松完成此操作的方法，那就加分了。我知道这可能是一个愚蠢的问题，但我需要在某个时候找到答案，所以最好现在就找到答案。
I'm working at a company that uses Perforce, and find it really annoying that when I edit something locally for a purely local purpose (maybe I want to change a path to point to something local for testing, etc...), that change is automatically added to my pending changelist and winds up cluttering it up. Intuitively, this seems strange, and in practice it's pretty annoying. It also makes it look to others like I'm editing the file and plan to upload it back to the depot, when this isn't at all my intent. All of that said, is there a simple way to differentiate between edits I plan on submitting, and edits I only want to exist locally? I'm using the eclipse plugin for Perforce, so bonus points if someone can give me a way to easily do it there. I know this is probably a stupid question, but I'm gonna need to find the answer at some point, so it might as well be now.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为什么不创建一个单独的更改列表，将不打算签入的文件放入其中？它仍然会显示为正在对其他人进行编辑，但这为什么重要呢？将这些文件作为 CL 中的更改进行跟踪，可以让您在需要时轻松恢复到 Perforce 副本以及与任何传入更改合并。
安迪已经提到过“使可写”技巧。要从该位置恢复，您可以运行检查一致性操作。它将找到已修改但未签出的文件。这也是离线工作的好方法。使其可写，然后在重新联机时运行检查一致性。
另一种选择是将文件内容复制到剪贴板，告诉 perforce 删除该文件的本地副本，然后使用剪贴板中的内容在其位置创建一个新文件。从 Perforce 的角度来看，此时文件尚未同步到您的工作区。当您进行同步时，您将收到与现有本地文件发生冲突的通知，您必须通过强制同步或删除本地文件来解决冲突。
如果您经常编辑某个特定文件，另一种选择是使用您的客户端规范将其完全映射出来。 Perforce 不会尝试从仓库同步它，您可以根据需要维护本地等效项。
在某种程度上相关的说明...如果您发现自己经常这样做，请考虑 Perforce 中的内容可能并不像应有的那么通用。也许可以添加属性或环境变量，以便您可以覆盖某些设置而无需编辑文件。
Why don't you create a separate changelist into which you put files that you don't intend to check in? It is still going to show up as being under edit to others, but why does that matter? Having these files tracked as changes in a CL gives you an easy way to revert back to Perforce copy when you need to as well as merge with any incoming changes.
Andy already mentioned "make writable" trick. To revert back from that position, you can run the check consistency action. It will find files that were modified, but not checked out. This is also a good way to work offline. Make it writable and then run check consistency when back online.
Another alternative is to copy file contents to clipboard, tell perforce to remove the local copy of that one file and then create a new file in its place with contents from the clipboard. From Perforce perspective the file at that point hasn't been synched to your workspace. When you go to sync, you will get a notice of collisions with existing local files that you would have to resolve by forcing the sync or deleting the local files.
Another alternative if you edit a certain specific file frequently is to use your client spec to map it out completely. Perforce will not try to sync it from depot and you can maintain a local equivalent however you want.
On a somewhat related note... If you find yourself doing this a lot, consider that perhaps what's in Perforce isn't as general as it should be. Maybe a property or an environment variable could be added so that you can override some setting without editing the file.
好吧，我可以告诉你担心几件事 - 我不确定你是否可以真正解决其中任何一个问题，而不会以其他方式给自己带来一些痛苦......
一个建议是为你的工作创建一个分支，稍后将其集成回到主线。这样，您的小编辑就不会显示给其他人 - 除非他们出于某种原因使用您的分支。
我大胆猜测，您本地开发/测试的小编辑可能更多地表明您的代码库中可以改进某些内容。如果您正在调整文件来调整文件路径，那么，让文件本身变得更智能：从数据库中读取值，根据主机名进行切换，使用环境变量......等等。我认为你可以找到既改进代码又避免小烦恼的方法。
我发现 Perforce 非常灵活，并且确实旨在帮助您提高工作效率并总体上完成工作。如果您发现您正在与版本控制系统作斗争，那么您很可能可以采取更好的方法。
Well, I can tell you are worried about several things - I am not sure you can realistically fix any of them without causing yourself some pain in other ways...
One suggestion would be to create a branch for your work, that you later integrate back into the main line. That way your small edits don't show up to others - unless they are using your branch for some reason.
I would venture a guess that the small edits for your local dev/testing are probably more an indicator of something that could be improved in your code base. If you are tweaking files to adjust file paths, well, make the files themselves smarter: Read the values from a database, have switches based on host names, use environment variables... something. I think you can find ways to both improve the code and not have the little annoyances.
I find Perforce is incredibly flexible and really is intended to help you be more productive and generally get things done. If you find that you are fighting with your version control system, chances are you could be doing something a better way.
一种方法是右键单击该文件到“属性”，然后清除“只读”标志。
现在它是可写的，但尚未签出。
One way is to right-click on the file to "Properties", and clear the "Read only" flag.
It's now writable, but not checked out.