I have recently joined a small development team that is considering a new version control system. As it is part of a large organisation, we are likely to adopt the company standard of Rational Team Concert.
I have recommended that they should choose something much simpler, but I will probably not get my way.
I have a major concern that it will not play nicely with ReSharper, and will force me to change the way I work. I use ReSharper quite heavily to perform refactoring and have it create and move files for me.
Will I be able to do this with RTC? What is the friction like?
As a footnote, the team is currently using ClearCase (clearly suckers for punishment), and my ability to do refactoring is severely hampered. I cannot even create project folders and move files from within Visual Studio, let alone have ReSharper do this...
ReSharper shouldn't interfere with your Version Control software in any way.
I've used ClearCase with ReSharper in the past and didn't notice any friction. The only thing that I can think of is that you were using the ClearCase plugin for Visual Studio in which case I would advise you to stop.
As long as you use the Source Control application for checkins/checkouts/commits/etc, you should be good to go.
I've used ReSharper and RTC together for the better part of a year. RTC hasn't interfered with ReSharper in any way I can recall.
is there a way to create a task/activity report (say a weekly report) off tasks managed with Mylyn? I've been using Rachota TimeTracker which allows me to create reports (in html format)
http://rachota.sourceforge.net/en/demo.html
I've just started using mylyn (our company uses Embarcadero JBuilder which is is based on Eclipse), but I don't see anywhere in the Eclipse or Embarcadero docs about reporting capabilities.
Is it possible? Is it possible to query activities worked on a prior week and report statistics out of it (management like reports, you know;) I'm sure it is, but I haven't been able to google it out.
Thanks.
You're in luck, Tasktop Pro (the supported version of Mylyn) has reporting. It allows you to:
View all task activity times for the previous day, week, and month
Manually adjust times as necessary to account for meetings and discussions
Submit your adjusted times, on tasks you select, to your task repository
Create reports in various formats
I'd recommend this short video which explains the reporting features in about 6 minutes.
David Shepherd
Tasktop Technologies
As you already know by now, the reporting functionality is included into commercial Tasktop product, which is developed by the same people who created Mylyn. So, obviously they are not interested to include some features into a free version. Now you have two options, either buy Tasktop, or develop your own extension for Mylyn. The task data is stored in reasonable simple xml file, so you not necessarily have to create an Eclipse plugin.
the reporting feature was stripped from the project when it used to be called mylar, in 2007, and since the project went commercial never came back to the open source mylyn for obvious reasons..
I found this simple perl script which outputs a pretty basic text only report, good enough for me.
http://rachaelandtom.info/mylyn-report
No takers? Not surprised since I can't find anything on the subject. For what's worth, there is an experimental task/activity report available for Mylyn with the sandbox jar. However, I could not get mine to work as I'm tied up with a JBuilder installation behind a firewall (and I can't download anything on the corp network that is not pre-evaluated... it sucks, I know.)
I'm going to have to experiment with the mylyn sandox at home, but it would be great if someone knows of an easier, more stable alternative.
The home page for gchart, a client side charting add-in for Google Web Toolkit (GWT), has a long screed about how the project's only maintainer thinks his Google account has been hacked and because of that he will be "disavowing/abandoning my own project and Google account". Does that mean the project is an orphan? Is somebody taking it over?
There is always a risk on basing your project on somebody else's code because they may stop supporting it or abandon it during your project's life time, but it seems to me that with the fast evolution of Java and GWT, using gchart in a new project may be a big mistake. Am I right?
I've released Client-side GChart 2.7 in a brand-new Google Code project (untainted by the previous rootkitting of my laptop) that you can find here:
http://clientsidegchart.googlecode.com
For details on the new security-related improvements I've instituted in an effort to prevent a future breach, follow the "release notes" link on the home page to the GChart 2.7 release notes.
I wish it had not taken me so long to re-release. I was attempting to correct the part of the problem that was under my direct control: my deep ignorance of all things related to computer security and systems administration.
I encourage you to give the re-released, better-secured and administered, Client-side GChart 2.7 a second look.
John C. Gunther, Client-side GChart author
I would have to say so. If the only maintainer of the project has lost control of his account, using any subsequent versions of gchart could mean you're implementing malicious code un-knowingly.
Unless he spins up another project to move the code-base forward, I'd avoid it.
I would like to be able to create FogBugz cases directly straight from the editor in NetBeans. Specifically, I would like to be able to look at a JUnit run in the IDE, examine the failures and create cases directly using the information that is right in front of me (rather than cutting and pasting into a web browser, etc).
I see that NetBeans 6.5.1 ships with Bugzilla available by default and JIRA connectivity in some sort of beta form. Is there an equivalent FogBugz issue tracker?
PS: I am aware of the new plugin architecture of FogBugz 7. However, I have a realistic appreciation of the time that I would be able to commit to creating my own plugin for either NetBeans and / or FogBugz and I suspect that I would be able to make just enough of a partial solution to make my life worse rather than better.
It appears you may need to write one yourself, as they have plugins for Eclipse and Visual Studio, but not Netbeans.
http://www.fogcreek.com/fogbugz/blog/post/Eclipse-Plugin-For-FogBugz.aspx
I am not aware of such plugin. You're right that it is not trivial effort to write full-featured connector, but getting basic one is not that hard ... especially if you're already familiar with NetBeans plugin architecture. If you decide to go for it, take a look at FogBugz API instead of new FogBugz plugins. FogBugz API is used to talk to remote FogBugz repositories.
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system