the company I work for have started to use Mercurial as our version control software, with NetBeans becoming the editor of choice for most developers.
Up until now we've been using WinMerge and KDiff3as our Mercurial merge tool, but have decided that we don't like it.
Now one of the things we've noticed about NetBeans is that it has a very nice diff tool built into it, so was hoping that there might be some way of using this as the Mercurial merge tool?
Can anyone let me know if this is possible, and if so, how?
(Or, are there any other windows diff/merge tools that are as good as the NetBeans diff tool?)
Cheers
I am not sure about using the NetBeans diff tool but as for other merge tools that will work well with Mercurial, I would recommend Perforce's Merge tool which I have heard is somewhat similar to the Netbeans one.
Another good one is DiffMerge.
As near as I can tell, there is no way to call Netbean's diff/merge tool from the command line, which is necessary to use it from Mercurial.
FWIW: I use Beyond Compare 3 for all of my diff / merge activities, even though I use Netbeans as a primary editor, and it does have Mercurial integration.
Functionally, I find the Beyond Compare interface to be a little easier, and it comes with a number of other features that I didn't think I needed, but have since grown completely dependent on, such as performing text diffs on entire folders, image diffs, and pushing changes between files that are being diffed.
Related
While I make some (java) code, i feel the need to experiment and change some parts of it often.
I want these changes to appear in a copy of my existing project and not the original - something like "save as" vs "save".
I have some options to do this job(below). Problem is that I can't decide which one to choose.
As a beginner to version control, I want something that is very easy, but is also used in many software companies. I already have a lot of problems with compiler and run-time errors. I hope that a version control software will not make the coding process even more difficult.
Options-
1- Make copies of my code and label them with different numbers/dates.
2- Use SVN ?
3- Use GIT ?
Besides this, are there any other version control methods ?
EDIT-
Is is possible to do SVN inside eclipse itself or maybe integrate eclipse with some SVN software ? If yes, would this be a good approach ?
I currently use SVN for personal projects and Git for group projects. The way Git handles branching is pretty slick. SVN is just really easy to set up and use (you just need a URL as opposed to a ssh login on the client side).
If you're using Windows, I'd suggest using the TortoiseSVN and TortoiseGit.
https://tortoisegit.org/
http://tortoisesvn.net/
I'd also suggest not going with the first option. Revision control is pretty important, even if you're just a hobbyist.
This obviously requires the source file to be under source control. I would ideally like a tool which works under the IDE (Eclipse, Visual Studio, etc) - but an external tool would be nice, too. Obviously, it is possible manually go through previous versions of the file, and compare the various versions, but I am looking for a way to be able to see quickly who is responsible for a code section.
I am using CVS, but the tool should ideally work with different source control systems.
That looks like the blame function, supported in eclipse with CVS, or with Subversion (also in eclipse)
As you mention, the eclipse-name for that feature is Show Annotations.
You don't mention wich source control are you using.
If you're using Subversion, you can take a look at:
svn blame
:)
For Visual Studio .NET with TFS.
The function is "Annotate" and works pretty much the same with Blame.
(personally I refer to these as the team's witch hunt tool).
The question is quite broad/open. Somehow, it is a good idea, it can be used as reference...
At work, I use Perforce with its graphical interface. The Time-lapse view allows to see the file with, for each line, the revision version in which it has been changed, and details (who submitted the change, when, etc.). And you can move a slider to see previous versions.
There is a command line version: p4 annotate.
I am starting to use Mercurial so I looked at it. Version control systems comparison (good site, I just discovered it) shows that the command is hg annotate.
In many version control systems including CVS, Perforce, AccuRev, Mercurial, and Team Foundation Server, the command is annotate.
In Subversion and RCS, the command is blame.
For example, with CVS:
cvs annotate foo.cc > foo_changes.txt
will create foo_changes.txt, which lists the revision number and username associated with the most recent change for each line in the current version of foo.cc. Using different options will give you the same info for previous versions or tagged versions of the file.
I needed this question answered too, but it didn't jump out at me right away when reading the answers already posted, so hopefully this summary should help.
In AccuRev this is even smarter with the annotate + "version slider" function, which will give you the option to browse through the annotated version of the file in history:
(Not only who changed what on the latest revision, but also on all revisions)
(source: accurev.com)
For perforce plugin in Eclipse annotate is not showing up in the context menu.
So I need to use: p4 annotate my-file and then using Eclipse browse the history.
I've personally always used some type of external application for my SCM work; these days, that means tortoiseSVN on windows and versions.app on the mac. However, I keep running up against developers (namely eclipse users) who argue that SCM is better done within the IDE itself. I've yet to hear any really compelling arguments in favor of this workflow, and I personally like a degree of "separation" between the IDE and SCM operations. This has been burned into me from using unstable SVN plugins in Visual Studio, and the sub-standard SVN support in Xcode in years past when working offline.
Which way promotes the better workflow in your opinion?
For basic operations - Check in Check out I like it right in the IDE, for anything much more advanced, (branch/merge) I prefer to use the external tools.
External tools seems to give better control/options in those circumstances. Your choices seem to be limited or non-existent when working directly in the IDE.
I definitely prefer outside. That being said, my primary IDE is Visual Studio, and I haven't used eclipse or intellij (although I have used cvs-mode in emacs...), so your mileage may vary...
Making changes and committing changes are separate tasks - having them both be easily available in the IDE means you don't clearly delineate between completing a set of changes and committing them. Quite often it's a case of type type type, compile, test, test, commit...'oh, wait - I forgot to foo the bar as well. Context switching from IDE mode to SCM mode tends to trigger the 'oh, wait' before the commit.
Keeping related files for commits together - it's all too easy to commit source changes, then remember the related SQL scripts and commit those separately and then add the new image files as you forgot those because they're new to the repository and so on.
Similar to the above, it tends to be a lot easier to commit things at the wrong level/directory in the repository when in the IDE. (e.g. I should have committed at solution level, not project level)
It tends to be easier to get a complete diff of your workspace against the repository outside the IDE, which is often worthwhile.
It also probably makes your IDE that extra bit faster
I also agree with a previous poster - all non-trivial SCM tasks tend to be easier outside development IDE integration.
To be honest, as long as you're avoiding messy commit situations described above, do whatever you find most comfortable. In terms of workflow - the separation has to be 'cleaner', whether this cleanliness outweighs the convenience is going to be in the eye of the beholder - we're largely reacting to our personal experience (I suspect mine is similar to yours).
Whatever you do, use anything but SourceSafe... I have to at the moment for legacy code - I find it abhorrent that files are made read only and that the SCM integration physically alters the contents of files...
One advantage to having the integration is in refactoring. If I renamed a class in Java (and thus the file name), your SCM integration would automatically handle the rename operation (a delete and then an add in svn, for example).
It also is very handy to be able to say, "show me the history of this file" or whatever while you are working on it, without having to drop to Windows Explorer or the command line or whatever.
But I like being able to have both available, honestly.
I almost always use external tools. The only exception is when I need to rename a source file. It is just so much easier for the IDE to update its project references at the same time.
It very much depends on the IDE/SCM combination. I'm currently using IntelliJ with SVN, and find that IntelliJ's SVN plugin is generally much more pleasant to use than Tortoise. Not that I have any particular complaints about Tortoise -- IntelliJ is just better.
Building should be possible without IDE so SCM should be possible without IDE.
On other hand, having IDE support the SCM can be convenient. It is nice to be able for example check the file history easily and maybe revert it.
I like internal SCM for.
Renaming files, rather than having to do the rename in the IDE and the SCM tools
Adding files to a project - see above
I find with an internal SCM it is less common for developers to forget to add new files to the SCM system.
For any complex operation, e.g. merge, branch, etc I tend to use an external SCM GUI or command line.
I'm looking for a tool like Atlassian's FishEye. The alternatives I've found so far (like StatCVS, ViewCVS or Bonsai) are either lacking in features or are quite a pain to install and maintain. So before staying with one of these tools, I'd like to be sure I did not miss any other good, easy to install, open-source (prefereably java) version control-viewer which supports cvs as scm.
Another SVN tool which has repository browsing capabilities is Trac. This is nice because as well as a browser for the repository it also has a timeline showing commits. It also does bug tracking.
Warehouse is pretty cool
ViewVC is a good open source, web based, repository viewer similar to FishEye. I know you've looked at it, and you're right, it was a hassle to set up, but once setup, it's run without any intervention for almost three years for us.
There is also CVS Monitor, though it hasn't got the nearly the number of features as FishEye.
We use ViewCVS for repository browsing.
If you were using SVN I'd highly recommend Tortoise SVN.
So I want to get a project on a distributed version control system, such as mercurial, git, or bazaar. The catch is that I need the Windows support to be good, i.e. no instructions that start off with "install cygwin...". Now I've heard that git's Windows support is decent these days, but don't have any first hand experience. Also, it sounds like the bazaar team has an explicit goal of making it as multiplatform as possible.
Can I get any recommendations?
I use msys-git on windows every single day. Works fast and flawlessly.
Although the newer build has some problems with git-svn, this build (Git-1.5.5-preview20080413.exe) has a working git-svn.
There's a nice comparison between git, hg and bzr in this InfoQ article. They all have their strengths and weaknesses. You'll have to think about your project and your workflows and choose the best fit. The good news is that they're all fairly good.
At last I checked, the only thing you need for Mercurial is Python and to grab a binary package. If you find yourself with more time and want to fiddle / build it yourself, look here.
The only real drawback with HG is its idea of branching .. but for some people that's a major plus.
I like it because its intuitive, easy to install and works on anything that Python does. I don't think that all of the available plugins will work for you, but most should.
I've had the best luck with Bazaar, followed by Mercurial. Never could get Git to work correctly. A quick search shows that Git still requires clunky emulation layers like Cygwin/MSYS, and I can't find any integration tools like TortoiseBzr for Git.
With Mercurial in Windows, I had several minor issues (insensitive paths, symlinks, ). They were usually fixed eventually, but I felt that the same quality of testing was not applied to running on Windows as for the other platforms. Bazaar also had better documentation for integrating with native applications like Visual C.
EDIT: Perhaps add a "dvcs", "distrubutedversioncontrol", "distrubuted"
I've used Mercurial on Windows with no problems. You can use TortoiseHG or just use the command line. Mercurial does require Python, but that is easy to install in Windows as well.
Mercurial Binary Packages
I agree with basszero. I'm using mercurial under windows and it's as easy and reliable as it can get. My development team is spread over Europe (well Dublin and Vienna :-).
We use VPN to commit or sometime the built in webserver (hgserve). Both work fine with no problems out of the box.
Also diff3 open source tool works perfect with mercurial and TortoiseHG out of the box.
If you are concerned about an easy to use interface:
The bazaar folk now include TortoiseBzr in their windows binary package. That's got to be a pretty strong indicator that they think it is up to snuff. I don't know what the maturity/stability of TortoiseHg is, but there certainly isn't a decent GUI interface for git yet, and the MSYS git build still needs some work IMO.
If your team are comfortable with or prefer the command line, then either bazaar or mercurial would probably work well for you, and are both probably about the same in terms of learning curve. Git's learning curve is much higher. It is like the swiss-army knife that is almost wider than it is long, with all the little gadgets and do-dads in it and hanging off it, with the springs so tight that you occasionally slice a finger open trying to prise a blade out.
In my experience using GIT on windows is a major pain. But I have been using Fossil SCM for some time now, and I think it actually fits your needs exactly.
It also has a built in Ticket system and a Wiki. And the whole program is contained in 1 file and it works right out of the box.
I totally recommend it.
Here is a link to the site http://www.fossil-scm.org/
Remember, this site is self hosting, what that means is you are looking at the web interface to fossil it self, when you look at tickets and the wiki and documentation, you actually are using fossil.
But if your project has millions of lines of code and is a few gigabytes in size, you have to use GIT, there is no way around that problem.
Enjoy.