我有一个问题。当我更新我的代码时出现了冲突，不幸的是我将该文件重新编译为以前的版本而不提交该代码。我失去了所有3-4天的工作。是否有可能获得未提交给svn但刚刚被svn修改的代码。
答案 0 :(得分：4)
不，如果您有从未提交过的本地更改，并且您还原了这些文件，那么这些更改很可能会丢失。
我想将此添加为评论但是时间过长了..
避免在未来发生类似事情的最佳做法是养成经常犯罪的习惯，一天几次。如果您所做的更改具有更大的范围并导致构建失败，请创建一个分支并在那里提交您的工作进度，直到它准备好我合并回主干。但是，如果不提交代码，请不要长时间工作。事故可能发生，失去几天的工作可能会令人非常沮丧！
答案 1 :(得分：1)
很抱歉，当您还原更改时，您无能为力。你基本上告诉Subversion废弃一切。顺便说一句，与其他人提到的不同，使用分布式版本控制系统不会有帮助。如果有人更新了您已经处理过的远程存储库中的文件，则无需先提取更改即可将更改推送到远程存储库。 （您可以创建一个分支并推送您的更改，但无论如何您也可以使用Subversion。）
与一群人合作的诅咒以及版本控制系统多年来一直在努力解决的问题。基本上，如果您和其他人更改了同一个文件，您需要确保在签入之前将其他人的更改合并到您的版本中。否则，他们的更改将会丢失。
通常Subversion会毫无问题地进行更新（尽管您应该进行测试以确保您的更改能够与文件的更新版本一起使用）。那么，如果在更新期间发生冲突，您应该怎么做？
不要惊慌！查看冲突消息，看看它的内容。很多时候，它类似于您删除的文件的传入更新，或删除您更新的文件。这些通常不是太大的问题，您可以使用svn resolved将情况标记为已解决。有时，它是单个文件中的行冲突。看一下冲突吧。 Subversion使用>>>>>>和<<<<<<<标记它们。绝大多数时候，它很容易解决。您添加了foo = bar，他们添加了snafu = bloop，您确实需要这两行。有时，这是一个行间距冲突。他们重新缩放文件，并且确实没有冲突。仅仅因为报道冲突并不意味着确实存在冲突。
在最糟糕的情况下，只需签出新的工作副本并使用它。但是，如果您这样做，请盲目地将更改的文件复制到新的工作副本上，因为您将销毁其他人的更改。
您始终可以创建分支并将代码提交到该分支，并在以后解决您的问题。这是分支的一个很好的理由。
无论你做什么，都不会恢复并失去所有的工作。
你是否使用带Time Machine的Mac？我也了解Windows的新版本 version 文件。您可以使用版本化备份来恢复更改。
将其视为一次机会。当我是一名程序员时，事情会一直发生在我将失去大量工作的时候，我不得不从头开始。通常发生的事情是我第二次编写了更好的代码。我对这个问题比较熟悉。我知道导致我如此悲痛的陷阱。
有时候，当我编程时，我可以选择两条路径中的一条。几天之后，我意识到我选择的路径是错误的，我一直在努力，因为我已经花了很多时间在这个项目上。当我处理问题时，代码变得更加丑陋和肮脏。我会诅咒自己做出错误的决定，但我必须忍受它。
失去一切让我以不同的方式做事。你曾经解决过这个问题，你知道什么是有效的，什么是错的。你花了四天的时间工作，但你可以在一天内重做大部分工作，这一次，做得对。