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.
Related
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'm running an open source ecommerce store (nopcommerce) and have made a lot of customizations to the store.
Every time a new version of the software is released, I use winmerge to try to detect which files have changed, and then merge these changes into the project. This works OK but as my customization have grown, this task has become increasingly problematic.
What I'd really like to do is be able to get a diff from my current version to the new version, and then go through and apply the changes that I want.
If I use TFS for this, is there a standard way to accomplish this? Perhaps a 3-way merge app would do the job better?
To complicate things a bit further, I'm using the theming support to add my modified views in another location, so the changes from version to version need to be figured out and applied to the files in this additional folder as well.
In fact this is where the big headache comes in- determining which changed I made, and which ones are new changes from the new version.
nopCommerce hosts its source code in Mercurial via CodePlex. All you really need to do is clone their repository and make changes to your local clone. Then, you can either keep up with their modifications or wait until the next release comes out, then get an update from their repo and merge it with your changes. Mercurial, being a distributed version control system, just does merges well, and you will have fewer problems if you try to do something manually for yourself using Subversion, TFS, or anything but Mercurial. Go download TortoiseHg, which gives you both a nice GUI and the command-line tools for Mercurial. TortoiseHg comes with the KDiff3 merge tool, but I highly recommend Beyond Compare. It's not free, but I'd pay for this software a hundred times over.
As always, if you need help with using Mercurial, see the Hg Book.
I have used both TFS and Subversion and I strongly recommend Subversion (source repository) with TortoiseSVN (command line) and VisualSVN (integrated into Visual Studio).
With these tools, it is very, very easy to find out exactly what files have changed and, more importantly, rollback to a previous version in the event that something goes horribly wrong.
You can also add CruiseControl continuous integration to automatically build your solution and run unit tests on each checkin to ensure that you didn't inadvertently break something.
I work on a large project where all the source files are stored in a version control except the project files. This was the lead developer's decision. His reasoning was:
Its to time consuming to reconcile the differences among developers' working directories.
It allows developers to work independently until their changes are stable
Instead, a developer initially gets a copy of a fellow developer's project files. Then when new files are added each developer notifies all the rest about the change. This strikes me as far more time consuming in the long run.
In my opinion the supposed benefits of not tracking changes to the project files are outweighed by the danger. In addition to references to its needed source files each project file has configuration settings that would be very time consuming and error prone to reproduce if it became corrupted or there was a hardware failure. Some of them have source code embedded in them that would be nearly impossible to recover.
I tried to convince the lead that both of his reasons can be accomplished by:
Agreeing on a standard folder structure
Using relative paths in the project files
Using the version control system more effectively
But so far he's unwilling to heed my suggestions. I checked the svn log and discovered that each major version's history begins with an Add. I have a feeling he doesn't know how to use the branching feature at all.
Am I worrying about nothing or are my concerns valid?
Your concerns are valid. There's no good reason to exclude project files from the repository. They should absolutely be under version control. You'll need to standardize on a directory structure for automated builds as well, so your lead is just postponing the inevitable.
Here are some reasons to check project (*.*proj) files into version control:
Avoid unnecessary build breaks. Relying on individual developers to notify the rest of the team every time the add, remove or rename a source file is not a sustainable practice. There will be mistakes and you will end up with broken builds and your team will waste valuable time trying to determine why the build broke.
Maintain an authoritative source configuration. If there are no project files in the repository, you don't have enough information there to reliably build the solution. Is your team planning to deliver a build from one of your developer's machines? If so, which one? The whole point of having a source control repository is to maintain an authoritative source configuration from which you build and deliver releases.
Simplify management of your projects. Having each team member independently updating their individual copies of your various project files gets more complicated when you introduce project types that not everyone is familiar with. What happens if you need to introduce a WiX project to generate an MSI package or a Database project?
I'd also argue that the two points made in defense of this strategy of not checking in project files are easily refuted. Let's take a look at each:
Its to time consuming to reconcile the differences among developers' working directories.
Source configurations should always be setup with relative paths. If you have hard coded paths in your source configuration (project files, resource files, etc.) then you're doing it wrong. Choosing to ignore the problem is not going to make it go away.
It allows developers to work independently until their changes are stable
No, using version control lets developers work in isolation until their changes are stable. If you each continue to maintain your own separate copies of the project files, as soon as someone checks in a change that references a class in a new source file, you've broken everyone on the team until they stop what they're doing and carefully update their project files. Compare that experience with just "getting latest" from source control.
Generally, a project checked out of SVN should be working, or there should be tools included to make it work (e.g. autogen.sh). If the project file is missing or you need knowledge about which files should be in the project, there is something missing.
Automatically generated files should not be in SVN, as it is pointless to track the changes to these.
Project files with relative path belong under source control.
Files that don't: For example in .Net, I would not put the .suo (user options) web.config (or app.config under source control. You may have developers using different connection strings, etc.
In the case of web.config, I like to put a web.config.example in. That way you copy the file to web.config upon initial checkout and tweak what settings you'd like. If you add something that needs to be added to all web.config, you merge those lines into the .example version and notify the team to merge that into their local version.
I think it depends on the IDE and configuration of the project. Some IDEs have hard-coded absolute paths and that's a real problem with multiple developers working on the same code with different local copies and configurations. Avoid absolute path references to libraries, for example, if you can.
In Eclipse (and Java), it's fine to commit .project and .classpath files (so long as the classpath doesn't have absolute references). However, you may find that using tools like Maven can help having some independence from the IDE and individual settings (in which case you wouldn't need to commit .project, .settings and .classpath in Eclipse since m2eclipse would re-create them for you automatically). This might not apply as well to other languages/environments.
In addition, if I need to reference something really specific to my machine (either configuration or file location), it tend to have my own local branch in Git which I rebase when necessary, committing only the common parts to the remote repository. Git diff/rebase works well: it tends to be able to work out the diffs even if the local changes affect files that have been modified remotely, except when those changes conflict, in which case you get the opportunity to merge the changes manually.
That's just retarded. With a set up like that, I can have a perfectly working project containing files that are subtly different from everyone else. Imagine the havoc this would cause if someone accidentally propagates this mess into QA and everyone is trying to figure out what's going on. Imagine the catastrophe that would ensue if it ever got released to the production environment...!
I need to keep under version some large files (some Gigs).
I don't need, and I can't keep under version all the version of the files.
I want to be able to remove from my VCS large files version at some moment.
The files that I want to keep under version control are big .zip files or ISO images.
These files may contains executable software or data (seismic data, SAR images, GNSS data) and they are provided by the software supplier of my company.
What control version system could I use?
In CVS you can do that by removing the files from the repo. Subversion allows that by dumping the content of the repo and filter it to remove the files (that is a bit cumbersome). Perforce has an obliterate command for that. Many of the newer distributed VCS make it rather difficult by their usage of hashes all over the places and the fact that your repo may have been replicated elsewhere also complicate things. Hg has a strip command (part of the Mq extension), Git can also do that I think.
I don’t think there’s any version control system that allows you do that regularly because that goes against everything version control systems stand for.
Perforce generally allows files to be put in two way, as head revision only (so, you'd only every have one copy) or all revisions. Perforce does have the admin level obliterate command that can be used to delete revisions. Its up to you to query for a list of files, possibly by date or number of revisions, and to specify the revisions to the obliterate command. As the name suggests obliterate deletes the revisions permanently from the database, so, I always generate scripts to do this and review them before running them. If the obliterate command is NOT run with the -Y flag, it will generate a list of what would be obliterated, also very useful.
Somehow I get the impression that you should not use a version control system at all. As said before, what you're trying to do goes against everything you would need a version control system for in the first place.
I suggest you create a file system directory structure that makes sense for what you're trying to accomplish and so that you can structure your data. And just make backup's of those files.
TFS has a destroy command that you can use to permanently delete files or revisions as you see fit.
There is more information at this MSDN article.
Many version control systems allow you to configure them in a way so that they store only the differences between several versions of a file and save space through that.
For example if you have a 1Gig file committed, change a part of it and commit it again, only the changed part will be stored in the version control system.
There won't be 2Gigs used (initial and new file) but only 1Gig+sizeOfChanges.
There's just one downside:if you're storing files which change their whole content from revision to revision this can also be counter-productive as the changes take almost the same space as the original version. Archive files are a example for such files where only a small change in the (real) content can lead to a completely changed content of the archive file.
I'd suggest to test several version control systems on your own and with your specific needs and environment and monitor each one at the server-side how the storage requirements for each system changes.
Some distributed version control systems allow to create "checkpoints" that allow you to use this version as kind of a base revision and safe you from pulling all the history before the checkpoint on every checkout. So you can remove the big files, create a checkpoint, and checkout/clone the repository from that checkpoint to a new directory. Then you have there a new, small repository, but without the history before the checkpoint. It you don't need that history you can burn the old repository on CD and use the new, partial one from now on.
I've only tested it in darcs, and there it works, but YMMV depending on version control system and use cases.
It sounds to me like you need an intelligent backup system, rather than version control.
I use SyncBackSE; it allows you to keep a number of previous versions, and can also do things like "ignore all files changed more than 30 days ago".
It's one of the few bits of paid-for software I use. I think it's worth checking out.
I think you're talking about something like "AlienBrain" "bucket" system, aren't you? The ability to remove some revisions from version control.
If you want to destroy an item, it's normally called "obliterate" and it's supported by a number of systems out there.
Buckets, AFAIK are supported by:
AlienBrain
Accurev
PlasticSCM
I would save such files under a unique name (datestamped, perhaps), and perhaps additionally make a textual reference to the external file in the version control system.
Fossil allows you to do this via the "shun" mechanism. Fossil being a distributed SCM, however, means that this does not affect all repositories (for obvious reasons).