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.
Related
We are starting on a new project and would like to know if we need store Ecipse IDE specific files (.settings, .project, .classpath) as part of our source tree. Should we ask each developer to create these files via the "mvn eclipse:eclipse" command or should we check it in for them. What would be the best practice here
We store them in Git, because we want every developer to work with the same environment. If you let every developer create their own project configuration, and have no other control about the configuration they use, you may end up with different configuration that leads to failures.
The major advantage of keeping IDE/environment configuration files in source control is to standardize your development environment.
Having a standardized environment confers several advantages:
Your environment and tool-set become familiar to all.
Common issues are well known and documented.
Easy learning curve for new developers (perhaps even a 'setup document').
Of course, there are also disadvantages:
By forcing your developers to code a certain way, you may be decreasing their productivity. For example, I'm most experienced with Eclipse. Sure, I could use NetBeans but I wouldn't be as efficient.
Developers may become less exposed to new tools/ideas/technology. For example, I use Eclipse primarily but I switch to NetBeans for profiling and IntelliJ for editing EJB configuration.
One of the better policies I've seen is "Hey, we're a Windows/Eclipse shop. You can use [insert your favourite OS/Tool/Technique here] if you like but you must be competent enough to fix your own problems".
This outlook seems to get the best of both worlds; the majority of developers will stick to the standard, document bugs, produce setup documentation etc. However, a small body of (usually senior) developers will go off and do their own thing, discover cool new tools and perhaps incorporate them into your standardized environment.
I'm looking for a subversion tool, and i have the following requirements:
Must integrate into VS 2008
Automatically submits new versions
Does not use the command line as primary interface
Doesn't clutter up explorer with bright icon overlays or context menus
is only going to be used by one user mostly if not completely, so doesn't need to have advanced diff tools or anything like that
Basically, i want a subversioning tool that will only bother me when creating a project or actually needing to get something from a previous version.
Does something like that exist, and if so, what is it?
Yes. VisualSVN (commercial)
Except for "automatically submits new versions" - that makes no sense.
The day computers know when your code is ready to be committed and free of bugs is the day the world needs a lot less programmers
You commit when you're done a task, which effectively gives you a rollback point. It's also important to add a meaningful commit message ("Fixed crash when clicking on Save button") - this way you can find things easily later. A lot of new users to version control skip this part, and unfortunately only learn the hard way 3 months later when they need to go back and undo a fix/feature.
AnkhSvn is a free alternative, I've personally only used 1.x, which was really quite terrible. It definitely looks more usable in 2.x.
One upside to VisualSVN is that it uses TortoiseSVN for a lot of its dialogs. This means when you're working with subversion just from explorer, you have basically the same interface and same UI. Quite handy, as it lets you do things like edit images or text files without having to fire up VisualStudio, or edit scripts/installers, or other parts of a product that are not necessarily in VisualStudio.
Yes, they are available.
The two I know of are VisualSVN and AnkhSVN. There are a bunch of comparisons available on SO
I use AnkhSVN myself. It is free, integrates nicely with Visual Studio, and doesn't cause any performance issues.
visual SVN is what you need.
Putting development tools (compilers, IDEs, editors, ...) and runtime environments (jre, .net framework, interpreters, ...) under the version control has a couple of nice reasons. First, you can easily compile/run your program just by checking out your repository. You don't have to have anything else. Second, the triple is surely version compatible as you once tested it. However, it has its own drawbacks. The main one is the big volume of large binary files that must be put under version control system. That may cause the VCS slower and the backup process harder. What's your idea?
Tools and dependencies actually used to compile and build the project, absolutely - it is very useful if you ever have to debug an issue or develop a fix for an older version and you've moved on to newer versions that aren't quite compatible with the old ones.
IDE's & editors no - ideally you're project should be buildable from a script so these would not be necessary. The generated output should still be the same regardless of what you used to edit the source.
I include a text (and thus easily diff-able) file in every project root called "How-to-get-this-project-running" that includes any and all things necessary, including the correct .net version and service packs.
Also for proprietry IDE's (e.g. Visual Studio), there can be licensing issues as this makes it difficult to manage who is using which pieces of software.
Edit:
We also used to store batch files that automatically checked out the source code automatically (and all dependencies) in source control. Developers just check out the "Setup" folder and run the batch scripts, instead of having to search the repository for appropriate bits and pieces.
What I find is very nice and common (in .Net projects I have experience with anyway) is including any "non-default install" dependencies in a lib or dependencies folder with source control. The runtime is provided by the GAC and kind of assumed.
First, you can easily compile/run your program just by checking out your repository.
Not true: it often isn't enough to just get/copy/check out a tool, instead the tool must also be installed on the workstation.
Personally I've seen libraries and 3rd-party components in the source version control system, but not the tools.
I keep all dependencies in a folder under source control named "3rdParty". I agree that this is very convinient and you can just pull down the source and get going. This really shouldnt affect the performance of the source control.
The only real draw back is that the initial size to pull down can be fairly large. In my situation anyone who pulls downt he code usually will run it also, so it is ok. But if you expect many people to pull down the source just to read then this can be annoying.
I've seen this done in more than one place where I worked. In all cases, I've found it to be pretty convenient.
Almost any IDE creates lots of files that have nothing to do with the application being developed, they are generated and mantained by the IDE so he knows how to build the application, where the version control repository is and so on.
Should those files be kept under version control along with the files that really have something to do with the aplication (source code, application's configuration files, ...)?
The things is: on some IDEs if you create a new project and then import it into the version-control repository using the version-control client/commands embedded in the IDE, then all those files are sent to the respitory. And I'm not sure that's right: what is two different developers working on the same project want to use two different IDEs?
I want to keep this question agnostic avoiding references to any particular IDE, programming language or version control system. So this question is not exactly the same as these:
SVN and binaries - but this talks about binaries and SVN
Do you keep your build tools in version control? - but this talks about build tools (e.g. putting the jdk under version control)
What project files shouldn’t be checked into SVN - but this talks about SVN and dll's
Do you keep your project files under version control? - very similar (haven't found it before), thanks VonC
Rules of thumb:
Include everything which has an influence on the build result (compiler options, file encodings, ASCII/binary settings, etc.)
Include everything to make it possible to open the project from a clean checkout and being able to compile/run/test/debug/deploy it without any further manual intervention
Don't include files which contain absolute paths
Avoid including personal preferences (tab size, colors, window positions)
Follow the rules in this order.
[Update] There is always the question what should happen with generated code. As a rule of thumb, I always put those under version control. As always, take this rule with a grain of salt.
My reasons:
Versioning generated code seems like a waste of time. It's generated right? I can get it back at a push of a button!
Really?
If you had to bite the bullet and generate the exact same version of some previous release without fail, how much effort would it be? When generating code, you not only have to get all the input files right, you also have to turn back time for the code generator itself. Can you do that? Always? As easy as it would be to check out a certain version of the generated code if you had put it under version control?
And even if you could, could you ever be sure that didn't miss something?
So on one hand, putting generated code under version control make sense since it makes it dead easy to do what VCS are meant for: Go back in time.
Also it makes it easy to see the differences. Code generators are buggy, too. If I fix a bug and have 150'000 files generated, it helps a lot when I can compare them to the previous version to see that a) the bug is gone and b) nothing else changed unexpectedly. It's the unexpected part which you should worry about. If you don't, let me know and I'll make sure you never work for my company ever :-)
The major pain point of code generators is stability. It doesn't do when your code generator just spits out a random mess of bytes every time you run (well, unless you don't care about quality). Code generators need to be stable and deterministic. You run them twice with the same input and the output must be identical down to least significant bit.
So if you can't check in generated code because every run of the generator creates differences that aren't there, then your code generator has a bug. Fix it. Sort the code when you have to. Use hash maps that preserve order. Do everything necessary to make the output non-random. Just like you do everywhere else in your code.
Generated code that I might not put under version control would be documentation. Documentation is somewhat of a soft target. It doesn't matter as much when I regenerate the wrong version of the docs (say, it has a few typos more or less). But for releases, I might do that anyway so I can see the differences between releases. Might be useful, for example, to make sure the release notes are complete.
I also don't check in JAR files. As I do have full control over the whole build and full confidence that I can get back any version of the sources in a minute plus I know that I have everything necessary to build it without any further manual intervention, why would I need the executables for? Again, it might make sense to put them into a special release repo but then, better keep a copy of the last three years on your company's web server to download. Think: Comparing binaries is hard and doesn't tell you much.
I think it's best to put anything under version control that helps developers to get started quickly, ignoring anything that may be auto-generated by an IDE or build tools (e.g. Maven's eclipse plugin generates .project and .classpath - no need to check these in). Especially avoid files that change often, that contain nothing but user preferences, or that conflict between IDEs (e.g. another IDE that uses .project just like eclipse does).
For eclipse users, I find it especially handy to add code style (.settings/org.eclipse.jdt.core.prefs - auto formatting on save turned on) to get consistently formatted code.
Everything that can be automatically generated from the source+configuration files should not be under the version control! It only causes problems and limitations (like the one you stated - using 2 different project files by different programmers).
Its true not only for IDE "junk files" but also for intermediate files (like .pyc in python, .o in c etc).
This is where build automation and build files come in.
For example, you can still build the project (the two developers will need the same build software obviously) but they then could in turn use two different IDE's.
As for the 'junk' that gets generated, I tend to ignore most if it. I know this is meant to be language agnostic but consider Visual Studio. It generates user files (user settings etc..) this should not be under source control.
On the other hand, project files (used by the build process) most certainly should. I should add that if you are on a team and have all agreed on an IDE, then checking in IDE specific files is fine providing they are global and not user specific and/or not needed.
Those other questions do a good job of explaining what should and shouldn't be checked into source control so I wont repeat them.
In my opinion it depends on the project and environment. In a company environment where everybody is using the same IDE it can make sense to add the IDE files to the repository. While this depends a bit on the IDE, as some include absolute paths to things.
For a project which is developed in different environments it doesn't make sense and will be pain in the long run as the project files aren't maintained by all developers and make it harder to find "relevant" things.
Anything that would be devastating if it were lost, should be under version control.
In my opinion, anything needed to build the project (code, make files, media, databases with required program info, etc) should be in repositories. I realise that especially for media/database files this is contriversial, but to me if you can't branch and then hit build the source control's not doing it's job. This goes double for distributed systems with cheap branch creation/merging.
Anything else? Store it somewhere different. Developers should choose their own working environment as much as possible.
From what I have been looking at with version control, it seems that most things should go into it - e.g. source code and so on. However, the problem that many VCS's run into is when trying to handle large files, typically binaries, and at times things like audio and graphic files. Therefore, my personal way to do it is to put the source code under version control, along with general small sized graphics, and leave any binaries to other systems of management. If it is a binary that I created myself using the build system of the IDE, then that can definitily be ignored, because it is going to be regenerated every build. For dependancy libraries, well this is where dependancy package managers come in.
As for IDE generated files (I am assuming these are ones that aren't generated during the build process, such as the solution files for Visual Studio) - well, I think it would depend on whether or not you are working alone. If you are working alone, then go ahead and add them - they will allow you to revert settings in the solution or whatever you make. Same goes for other non-solution like files as well. However, if you are collaborating, then my recomendation is no - most IDE generated files tend to be, well, user specific - aka they work on your machine, but not neccesarily on others. Hence, you may be better of not including IDE generated files in that case.
tl;dr you should put most things that relate to your program into version control, excluding dependencies (things like libraries, graphics and audio should be handled by some other dependancy management system). As for things directly generated by the IDE - well, it would depend on if you are working alone or with other people.
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