version-control

问题 I've recently started getting into Git on a personal project, and I can see how a DVCS might benefit us at work (which is a large enterprise software company, currently running Perforce). Feature work in my team for example mostly consists of developers creating their own branches; sometimes these are shared between small teams of developers. I think it would be more efficient in this instance to use a DVCS. In the more general case, though, I'd be interested to hear from people that use a

问题 I know how to do this in SVN, svn diff http://svn.example.com/branches/A/File1.txt http://svn.example.com/branches/B/File1.txt But there has to be a less painful way to do this in TortoiseSVN. You would think that you could do it from the Show Log, but it appears to only show revisions on the current branch. 回答1: Go to the repository browser (<right click>/TortoiseSVN/Repo-browser/<enter URL>). Open right click menu on branch B, select 'Mark for comparison'. Then open right click menu on

问题 Creating a patch is very easy in SubVersion, With Tortoise, you right-click and select Create Patch. But for the life of me, I can't find this functionality in TFS. Is this possible? If not, what's the standard way to submit patches in open source TFS hosted projects (a la CodePlex)? 回答1: tf diff /shelveset:shelveset /format:unified Edit: This writes to standard output. You can pipe the output to a file. For more options, see Difference Command. 回答2: Codeplex uses its own client for creating

问题 I'm getting confused with the include/exclude jargon, and my actual SVN client doesn't seem to have (or I've been unable to find it easily) a simple option to add or remove a certain type of files for version control. Let's say for example I've added the entire Visual Studio folder, with its solutions, projects, debug files, etc., but I only want to version the actual source files. What would be the simplest way to do that? 回答1: You're probably safest excluding particular filetypes, rather

问题 We have the convention of versioning our builds as [major].[minor].[micro].[revision], e.g. 2.1.2.33546. Our build-script automatically updates an AssemblyInfo.cs file containing [assembly: AssemblyVersion("x.y.z.w")] in order to embed the version-number in the assembly. But our Subversion-repository just reached revision #65535, which broke our build. It turns out that each number in the version-number has a maximum value of 65534 (probably due to a Windows-restriction). Have you encountered

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 5 years ago . I have the opportunity to give a formal presentation to my boss about anything that benefits the company. My idea is to adopt source control in my workplace. I have been using Mercurial to manage my own project at work, but the rest of the team does not have a formal source control system in place. Unfortunately

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 3 years ago . Specifically, I'm looking for something that, given a single file, and an SVN history, will display insertions and deletions as a pretty animation. That said: I figure that a list of version control visualizers might be a useful resource. 回答1: http://code.google.com/p/gource/ looks very pretty 回答2: I am not sure

问题 I've been working on code checked out from the development line and discovered that the changes made might be breaking changes and need to be moved to an experimental branch before committing to the main dev tree. However, I don't have the experimental branch checked out and I don't want to lose the changes that have already been made. Is there a way to commit the changes in the working folder to a different branch than originally checked out? 回答1: You should create a branch from a known

问题 I am using git and github, and I just finished the 1.0 version of my iOS app. From here, I am wondering how git can best serve me. I really am just looking for a best practice here, and what others recommend for managing major versions. Should I create a new branch for each new version, such as for 1.1, 1.5, 2.0, etc? Or should I just keep pushing to the master branch? If so, how do I do this? 回答1: I would recommend using tags (tag tutorial) From your master branch since you are done v1.0 add

问题 Even after reading this question: git-push-current-branch, I am still having difficulty figuring out how I should write my git push command. As mentioned in the question link, it's not clear from the documentation. I would like to use my 'real world' example. Following is what I see when I do a git status command on the top level of my branch: On branch amd_qlp_tester Your branch is ahead of 'origin/amd_qlp_tester' by 5 commits. etc... So my branch name is amd_qlp_tester but it was "branched"