Along comes a requirement to change the base code and get it into production last week without the breaking change.Īfter verifying that the new requirement doesn't break anything when using the revision before my check in, I made a copy of the working directory containing the new code. That was several months ago, and the integration has been stalled for that entire time. I recently found myself in a situation where I'd checked in breaking code, knowing that I couldn't update our production code to it until all the integration work had taken place (in retrospect this was a bad decision, but we didn't expect to get stalled out, but other projects took precedence). Here's another method that's unorthodox, but works*. Check the results, then commit the changes.Īll solutions are explained in the " How Do I." part of the TortoiseSVN docs. You have reverted the changes within your working copy. This will discard all changes after the selected revision. Or if you want to make an earlier revision the new HEAD revision, right click on the selected revision, then select Context Menu → Revert to this revision.Right click on the selected revision(s), then select Context Menu → Revert changes from this revision. Note that for multiple revisions, the range must be unbroken with no gaps. If you want to undo a range of revisions, select the first one and hold Shift while selecting the last one. Select the revision you wish to revert.You may need to use Show All or Next 100 to show the revision(s) you are interested in. Select TortoiseSVN → Show Log to display a list of revisions.If you want to revert all changes, this should be the top level folder. Select the file or folder in which you need to revert the changes.This is also the method to use of you want to discard recent changes and make an earlier revision the new HEAD. The easiest way to revert the changes from a single revision, or from a range of revisions, is to use the revision log dialog. But do not just update to the earlier revision as suggested here. TFS will try to kill you in your sleep.There are several ways to do that.SVN is still a good option, especially if you're already using it.Mercurial will change your life for the better.It may do some great things with continuous integration, but purely as a source control system it sucks. Mercurial commits locally so that isn't an issue.Īs for TFS, I loathe it. I can't follow the Mercurial workflow with SVN because if I do I break the build. With Mercurial, it's easy to see what I've done wrong as I have a more recent commit. If I make a mistake somewhere between changing method 3 and adding method 4 I'm stuck - I've got no way to revert other than doing some kind of manual diffing between the last commit and my current code state. Suppose I need to implement feature which requires the modification of three methods and the addition of two. Mercurial has completely changed the way I use source control. At the moment, TFS is just being used for source control/bug tracking. I use TFS, SVN and Mercurial on a daily basis. csproj files but I can live with that) but TFS is supposed to have a great deal of features. I know SVN Tortoise works (it has a few quirks around ASP.Net. To reiterate: my major concern is merging. It makes no sense to incur unnecessarly research costs. I want to hear answers from those who already know (as well as those who anticipate pitfalls). Therefore, I have asked the question on here. Running a TFS trial is likely to be costly to a business. Merges back into the trunk (head) occur after project completion. Checkins on a branch would occur at any time (only explicit rule is that it builds). The maximum team size to work simultaneously on a product would be less than six developers. Projects would typically last less than two weeks (large pieces of work would be broken down into these discrete chunks of this size). There would any ever be one develop stream per product. The Platform is Windows (does TFS run on anything else) and the intended use is version control through Visual Studio 2008 / 2010 with the scope for Continuous Integration on x86 or 64bit build servers (depending on the product). What advantages does it have over Tortoise SVN? For example, does the merging work seemlessly or does it involve a lot of manual work and does the shelving actually work (we could not get it working)? I used an earlier version of TFS for two years but I have not used it for years. This is neither a Holy War invocation nor is it - This question is much more specific and would potentially make a team of developers very happy:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |