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.
Related
I am using Eclipse with the "statet plugin for R".
I am looking for a way to do collaborative development (like in google docs: allow people to modify code at the same time). Any preferred plugin for that? I have seen eXtreme Collaborative Development Environment but I don't know if it is good?
I wouldn't use a shared drive, I'd set up a source code respository using Mercurial or Git and use that. I'm sure there's plugins for those for Eclipse.
How would you stop it being a free-for-all? In my experience, when developing code you want to control change, not have it forced upon you when you aren't ready for it.
Consider this scenario. You have a hard to explain defect in your code. You are steadily debugging it, throwing different data at it, looking at intermediate values etc. You are just about to trap it when BOOM, somebody else changes some other code and your results change because of that.
Spacedman is right, use a revision control system of your choice and keep in control of change.
If you want to do something like pair programming, but remotely, then use a remote screen, e.g. VNC, with Skype so that you can explain to the other what you are trying to achieve.
I've used egit to add git functionality to Eclipse with StatEt and it works well. Allows others to edit code in whatever way works best for them (one repository, several individual repositories with frequent merges etc)
There are plugins out there that will facilitate realtime code sharing. They commonly work by having all individual devs have their own copy of the files and synching changes back-n-forth on the fly. If conflicts are found you get to decide how to resolve them explicitly.
Here is one such plugin from ECF project:
http://wiki.eclipse.org/DocShare_Plugin
I would recommend a source control system for day-to-day development. Real-time code sharing works best for holding short-term collaborative editing or debugging sessions, doing code reviews, etc.
i.e. Do you put the whole package under VCS or just the components you are programming? Packages by there nature will get upgraded and that code will need to be added into the VCS, plus there is a lot of code that is static.
Specifically I am going to be working on Joomla, adding and building modules, customising modules and the look and feel. Initially this will be just me but will expand to possibly two more developers as the project ramps up. My reaction would be just to VCS the lot, it means that i know it is all there and deployment via CI is easier(?).
The alternative is to exclude the bulk of the code that is not being altered which could be error prone and laborious.
As there is not a specific answer for this and i am looking for either experience or best practice advice i have marked it community wiki.
I usually do one of two things (I use SVN):
Put a release version (no SCM meta-data) of the library/framework in a separate folder in my SVN repository. That way I know that the code is stable, and if something stops working, it's not because of changes to the framework, but instead my own fault (and can easily be fixed by me.)
Use svn:externals to automatically update from the official SVN of the library/framework. This is less safe, but is sometimes nice, especially when you are a contributor to the library/framework and can fix bugs that may occur yourself.
If you're using SVN, and want to use externals, do this:
svn propset svn:externals "foldername http://libdomain.com/svn/trunk" libs
...where libs is your library folder (onto which this SVN property will get set), and foldername is the name of the sub-folder in which this particular library should be placed.
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.
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
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.