I use Tortoise to interact with CVS for source control. When merging it shows you a diff of the files calling the one on your HD "Yours" and the one in the repository "Mine". Or maybe I have that backwards. As you can see that nomenclature confuses me. Then I also have to try to remember which to merge into.
Is there a setting to change that naming scheme? Maybe to "OnHD" and "FinalInRep".
Update 1
Mark Davidson, changing yours and mine
as your prescribed
I haven't tested it but go
TortoiseCVS-Preferences
Tools Tab
Two-way merge parameters
in that it currently has set "%mine"
"%yours", you might be able to change
them to something else, but have not
tested it.
Changes the paths my diff tool looks for, not what CVS calls the file. As such, it doesn't change what CVS displays, it breaks my merge tool.
I haven't tested it but go
TortoiseCVS-Preferences
Tools Tab
Two-way merge parameters
in that it currently has set "%mine" "%yours", you might be able to change them to something else, but have not tested it.
Related
I am using mercurial via tortoiseHg (windows) as a source control management tool.
I am used to merge using beyond a compare. Today, I have to perform a very complex merge and I just discovered a new feature (my client was updated some days ago) that is extremely annoying.
When I have a conflit and ask Mercurial to take the "other" file and keep the original in a .orig file, the .orig is added with <<<<<<< local and >>>>>>> other, but more than this, the other part is merged into the original one !!!
The two parts are then unaligned and it's impossible to guarantee that the merge is OK because you have to review it line by line with no help from the comparision tool. (see screen below).
http://s13.postimg.org/yor6gno47/Untitled.jpg
I want to disable this feature, but so far, I am unable to do it. Thanks so much for help as this is furthermore blocking my work.
Regards.
The launching of a specific merge tool isn't something Mercurial controls. It does, however, have a robust mechanism for Merge Tool Configuration that allows you to provide a preference order and it will use the first one it can find. The builders of various Mercurial installation packages (ubuntu, etc.) and tools that include Mercurial (TortoiseHG, etc.) all provide their own Merge tool configuration preference list.
Either the old merge tool configuration list you had not longer points to Beyond Compare at the right location (upgraded BC and the directory name changed, etc.) or you got a new merge tool configuration list when you updated some software that included mercurial. Either way that page on MergeToolConfiguration will help you find your preference list in your hgrc files and update or correct it.
Tl;Dr: this isn't a "new" feature it's your new installation being less tailored for your system than your old one. Maybe find who packaged that one and copy the merge tool config.
I am using Mercurial, but I imagine that any merge tool that is aware of the version control system below it could do several things that a merge tool which is not aware of the version control system and only sees two "files" in two different folders, could never do.
I have been using KDIFF3, and recently tried BeyondCompare, and neither of them will do this, at least not that I could figure out.
What I want to do is best shown in this picture, an annotation column and perhaps even ability to open other windows from those annotation columns so I could browse specific versions of specific files to see context when trying to do a merge.
In the image here, I am showing a two way merge, but the same applies for a three way merge. To the right or to the left of the actual file content being shown, I would like a gutter or a right side annotation column showing some kind of annotation of where this change came from. Since Mercurial hex ids are relatively unfriendly and unhelpful, and since repository-local-revision-numbers are repository local, I think that a short text description based on commit comments would be most helpful. Of course, with Mercurial, 99% of these commit comments are going to say "Merge", and nothing else. (Groan.) But lets pretend for a minute that we weren't using tools and workflows that left us that crippled at merge time, and instead, that we could have a useful commit comment show up each time:
Right now the workflow for complex merges looks like this for me:
Using my distributed version control tool (mercurial), pull changes from another repository which is in effect a branch. Merge. The merge window for TortoiseHg is usually where I start all this from. This in turn lets me configure a merge tool (beyond compare or Kdiff3).
However, it does not appear that there is any merge tool (that I have seen) that can be told, "hey you're not just merging two way or three way with different versions of a file in the two completely different folders, with the names I told you, but those files are also files that have a complete edit history available to you to show your human the actual context, the commits that those line changes came from with their commit comments, often having a bug number as part of the commit which will give the person doing the merge the ability to see What in the Heck is Really Going on.
I would change from Mercurial to Git, for example, even, for a real merge experience that didn't force me to do manually what I think my tools could be doing for me automatically. I'm using Mercurial, TortoiseHG, and KDIFF3, and if I could just change from KDIFF3 to some other tool, or do ANYTHING at all to get annotations and merges together on one screen, I would like to do so.
I am comparing two folders using a diff tool. I have tried a few different diff tools, but right now I'm using WinMerge. There are many files which show as unique to the right or left side, for example:
On the right we have: /bar/some_organized_characters.txt
On the left we have: /foo/some_similar_organized_characters.txt
The text file may have slight variations, but it's mostly similar. I would expect a tool to exist in most merge/diff tools which could tell you that these files are likely the "same" (meaning they have the same base), but the file has been moved, renamed, and slightly modified.
What I'm specifically trying to do is a "vendor merge." We have some customized software, and we want to merge the changes from a recent official release with the changes we have made. Many files have moved in the latest official release, and finding every move/rename by hand is difficult.
use a version control tool to check for changes. Simply commit the structure as an initial commit. Then overwrite the structure with the new version and commit that. The patch view will show you moved items. I've been able to do this with Git very easily. These tools are made to see how something has changed and will dig into the contents of the file. In fact, in git, you can set the threshold of what percentage of changes in a file constitutes a move and change, vs a delete and create.
I don't think this is possible with diff (I couldn't find it in the manpage).
However git diff detects this by default and can create patches that are applied with git apply in a similar way to patch. You can use it on arbitrary directories, not just repos, with --no-index (see Diffing between two entire directories/projects in hg or git?).
I once ran across a commercial tool for Windows that allowed you to "stash" code changes outside of source control but now I can't remember the name of it. It would copy the current version of a document to a backup location and undo your checkout in source control. You could then reintroduce your backed up changes later. I believe it worked with multiple source control systems. Does anyone know what program I'm trying to describe?
The purpose of my asking is twofold: The first is to find a good way to do this. The second is because I just can't remember what that darn program was and it's driving me crazy.
Git: http://git-scm.com/
You can use git stash to temporarily put away your current set of changes: http://git-scm.com/docs/git-stash . This stores your changes locally (without committing them), and lets you reintroduce them into your working copy later.
Git isn't commercial, but is quickly gaining many converts from tools like Subversion.
I think the product you're thinking of is "CodePickle" by SmartBear Software. However, it appears to be a discontinued product.
The term that seems to be used for the type of functionality you're looking for seems to be 'shelving'.
Microsoft's Team system has a 'shelve' feature.
Perforce has several unsupported scripts, including p4tar and p4 shelve
There are several 'shelving' tools for Subversion, but I don't know how robust they are.
I'm no git user myself, but several of my colleagues are, and they seem to like it precisely for this purpose. They use the various git wrappers to commit "real" changes to the SCM system used by their company, but keep private git repositories on their drives which they can keep their changes which they don't necessarily want to commit.
When they're ready to commit to the company's SCM server, then they just merge and commit upstream. Is that what you're looking to do?
Wouldn't it be a better idea to store your private changes in private branch, using e.g. svn switch to change to main branch whenever you need to?
Mercurial has the Shelve Extension which does what you want.
You can even select which changes from a single file that you want to shelve if you really want.
In Darcs, you either don't record the changes you want stashed (it asks you about including each change independently when you record a new patch), or put them in separate patches that you don't push upstream.
There's no need to fully synchronize your local private repos with public/upstream/other ones. You can just cherry pick the patches you want to push elsewhere. Selecting patches can also be done with patterns, so if you adopt a naming convention for your stashed patches you can push everything but them easily.
That way, your private changes are still in revision control, but they aren't shared until you want them to be.
I found an excellent article about obtaining similar functionality using Subversion branches:
Shelves-in-subversion
And then there's the old fallback... 'patch', or even the old "copy everything to another location, then revert".
Both of these are less convenient than using tools that are part of most VCS systems, though.
I'm having some issues with the DBML. Every time the team needs to synchronize changes into SVN, the DBML is changed which generates lots of conflicts. This seems to be related to some rearrangement in the dbml editor, because most of the associationConnector sections in the .dmbl.layout seem to change during development if you open the dbml file in the editor.
Do you have any best practices to avoid these layout rearrangements that can easily take more than one hour to fix?
Best regards,
Gustavo
If it is just the .layout being changed then I would actually ignore the request since the GUID's which link everything up will still match. They just won't be in the same place as I set them, something I could live with. If the .dbml changed as well, then I would accept both without merging.
If you willing to use KDiff3, then you can configure a pre-processor command to sort the dbml file before merging. I've posted a guide on my blog at http://blog.trumpi.co.za/the-one-tip-that-i-wish-i-knew-years-ago-that-merges-easier/. The instructions are for git, but I know that TortoiseSVN can be configured in a similar way to route dbml merging to KDiff3.