Ive been using eclipse and my-eclipse to code android and Java projects. I want to be able to back up my code. I know there is a way to back up code so that i can retrieve not only entire projects but changes and old versions but I cant figure out what the software is called and cant find any that are free and easy to implement. Any help would be great!
EDIT:
I don't have a server, can any of these be set up to save locally?
I think you'll want to use version control software. There are great solutions out there - CVS, SVN, Git, Perforce. Most of them integrate nicely into Eclipse.
Developing software without VCS is unthinkable to me.
Any of the plugins mentioned here will do, but I'm using the Subclipse plugin and a free repository at Assembla right now. I only switched from Mercurial because I started using Subversion at work.
If you don't have a server, you can try a free configuration at Assembla.com (http://www.assembla.com/catalog/tag/Free) for either Subversion or Git, and I've used Bitbucket.org in the past for hosting projects with Mercurial. Even the free configurations should be enough for your needs. I divided mine up between multiple projects.
Subversion (at subversion.tigris.org) is one excellent package; there are many others. There are excellent Subversion plugins for Eclipse (google "Subclipse".)
You may look to use the Subclipse package for Eclipse to use it with SVN. It permits you to keep/track/rollback changes and so.
The second option works fine if you need immediate result is to use Dropbox. It is easy to configure and easy to share the folders among multiple computer.
One more vote for using a VCS: in addition to back up you are getting control and some degree of methodology in your project.
Centralized solutions like CVS, SVN and Perforce mostly require setup and maintenance (some of them can run on flat files but these configurations are less popular). I would also consider one of the "Big Tree" distributed VCS Git, Mercurial and Bazaar.
Mercurial seem to have strong Eclipse plugin
Related
Me and my team were wondering how we could share our java project easily. I was thinking about using something like Google drive but it is quite tedious to download the files everytime any member wants to modify them. I know there exits easier ways to share a project for example using Eclipse but the problem is that we all work on either BlueJ or Eclipse. So is there a way to do it?
Thanks in advance
Are you familiar with SVN?
Developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. You can also add an eclipse plugin to update or checkout projects from a SVN server.
Or as of another solution, and making less effort in setting up a SVN server just use github.
here is the link where you can signup in their website
You can share the project with team using GIT or SVN.
1) It synchronize the project all the time when you(including your team) push or pull the code-changes to and from the server.
2) Easily compatible with eclipse.
I'm quite new to android programming and I was wondering if there is a Save As button in Eclipse for the entire project instead of saving only 1 XML or Java at a time.
For example, when I work on Excel, sometimes I like to save different versions of Excel workbooks so that I can roll back if there is a problem. I want to do the same thing for Eclipse project files like Listv1, List v2, Listv3 etc.
I know you can use local history, but that is more for different versions of the XML and Java files.
I want to save different versions of project files onto my hard drive so that I can compare two different versions of my project.
Click on your open project in either the Project Explorer or Package Explorer windows. Then File/Copy (or Ctrl-C), then immediately File/Paste (or Ctrl-V). Your'll get a wizard to save the project under a new name.
You need a lot more than manual saves: Any software project of any significant size should be using a version-control system. The one that's become the main standard these days is git.
Providing this sort of multiple versioning is the baseline that a VCS does, and most also handle situations like branching, where you can be working on the new version of your program but still go back and fix a bug in the old one, then push out a fix to the existing users while you keep working on the new version.
Eclipse has very good integration via the eGit plugin, and you might also be interested in the git-flow branching system.
I don't think that eclipse has that feature, why not having a a version control system to track your changes? like Git or Svn, they are free and very powerful
For example, when I work on excel, sometimes I like to save different versions of excel workbooks so that I can roll back if there is a problem.
Learn to use a good source control (version control) system. That's a much cleaner solution than just keeping lots of different copies around. You should still be able to compare different versions easily - and you can experiment on different branches, etc. It'll also make it much easier to share your code with others, should you wish to.
Additionally, it's not clear whether you're currently just a hobbyist or not, but if you're intending to code professionally you'll definitely need to get used to source control systems. (Every software company worth their salt uses source control.)
You might want to look at:
Git (you might want to start at GitHub)
Mercurial
Subversion
(All of these are free, and have Eclipse plug-ins available.)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We currently do not use any kind of version control software. We recently started using Eclipse, and our source code is maintained on a network drive. An Eclipse project was created and everyone has imported the project into Eclipse on their machines. Due to the way we are set up, we are always getting stuck in clean/build loops throughout the day which is hurting productivity.
We would like to start using some kind of VCS (most likely GIT). I am envisioning a centralized workflow with each developer having a local copy of the code on his/her machine. We would rather use GitHub Enterprise for the shared repository instead of hosting the code on GitHub.
I am not quite sure where to start in getting this setup correctly. I have been watching videos and reading tutorials, however none seem to directly apply to how we would like to do things. Is GIT the right software to use for the type of setup we desire? Also, how does clean/building work with Eclipse and the local copies vs the shared repository?
First, watch this video.
Second, if you're using Eclipse, you're gonna wanna use EGit. Very detailed tutorial here.
Third, don't throw yourself at GIT. Take SVN into consideration at some point (after documenting on GIT). Maybe a Central Version Control System will do you better than a Distributed Version Control System.
Edit:
Oh and by the way... there's a veeeeeeery long and famous Q&A right here regarding this topic. Best of luck.
Second edit:
As for SVN, here you have an easy tutorial on Subversive, and here you can find the full in-your-face Subversive documentation.
You have your needs now but your needs will change. Save yourself the headache of later moving to Git from SVN and start with Git. Here are the reasons to go with Git over Subversion:
Speed - Git is WAY faster
Disk space - Git history is small. Most of the time it takes up 1/10th the space of SVN history.
No server - DVCS allows no admin and you can skip a centralized server altogether. Your central repository can just be files on a network share.
Integrity - data corruption very easy to detect and correct.
Snapshot history - the whole project is snapshotted for each version. No mixing and matching paths with versions.
Open Source dependencies - most of the projects you may want to use are on Github. You can easily just add a submodule and version that dependency.
Power:
git bisect - find a where a bug was introduced quickly
rerere - reuse how you fixed conflicts if they come up again
supports any workflow
proper 3-way merges - this will save a ton of headaches in the future
rebasing - you can keep your history linear, even after someone merged
My last point is very important. You are just now starting to use source control. Start with the best option. You are at a point where you know the least about your needs. Things you think you don't need right now you will need later - guaranteed.
I would create a git repository on the shared drive, you don't need a server like github at all. After setting it up developers can clone from the shared drive to their local computer and push the changes back when they are done.
Every developer will end up with a local copy of the code where they have their own build environment and never be in each others way anymore.
Start with a sample project with just some files in it and play around with it, since you will need to get some experience with a version control system. Also learn the git command line tools (for windows use msysgit), because most of the examples on the internet are writen for those. For more information on git be sure to read the free git book: http://git-scm.com/book
Also see this question about using git on a windows share: How to git clone a repo in windows from other pc within the LAN?
EGIT for eclipse is the good one to integrate git in your eclipse project environment.
Besides, if you are on windows, you can download the Github for Windows, it's really simple, effective to use.
GIT is certainly the preferred way and nicely integrates with Eclipse IDE. But you could also use Subversion as all you want to have is a local copy of code on user machine(call it subversion branch). I say preferred way because GIT is way too flexible: Offline commits, full copy of body of code versus just branch etc....list is too long.
As you mentioned, you can also use github. Roughly, steps are as follows:
Just signup for it
create a repository.
Get the link to repository and Point it as new git repository in Eclipse
Push your code. Commit it.
You will have your code files in github. This will work provided you have Git installed in Eclipse. I believe Eclipse Juno already is setup with EGit (plugin for Git)
For resolving the build issues, you can use set up some Continuous Integration tools like Jenkins. This can be setup as Eclipse plugin as well.
As some already noted, for question
the best way to use GIT?
in your situation (zero SCM-experience) best and fair unbiased answer will be
Do not use Git at all!
Contrary to "Why is Git better than Subversion?" topic you can also read (some subset as result of fast-recall)
GIT - What gotchas should newcomers to version control be aware of?
What does SVN do better than git?
What are pre-requisites for learning & understanding Git?
and check other topics under git tag with multiple laments of Git-boys.
While Subversion is rather good choice (with some edge corners anyway: you may fall into "Merge Hell" even if you think about development as linear: some branches may and have to happen, into "Refactoring Nightmare" with famous "Tree conflict" error...) you can think about "Usable as Subversion and powerful more than Git" alternatives (even you'll use only small needed part or overall power): - Mercurial "DVCS with a human face, made by software engineers for software engineers, not for fashionable dudes".
MercurialEclipse is answer for Eclipse request (in Aragost recommendation Mercurial users trust)
TortoiseHG is user-friendly cross-platform GUI for all and any Mercurial needs outside Eclipse
Mercurial server require a lot less headache (notably "under Windows"), than equivalent Git-server
Mercurial real experts can be easy found (while Git-boys is more fun-club of rapturous teenagers)
what's the point of using ant, maven, and buildr? won't the using build in eclipse or netbeans work fine? i'm just curious what the purpose and benefit of extended build tools are.
Dependency Management: The build tools follow a component model that provides hints on where to look for dependencies. In Eclipse / Netbeans, you have to depend on a JAR and you don't really know if this JAR has been updated or not. With these build tools, they 'know' updates in dependencies (generally because of a good integration with your source control repository), recalculate transitive dependencies and ensure that everything is always built with the latest versions.
Access Control: Java, apart from class level access control, has no higher abstraction. With these build tools you can specify exactly which projects you want to depend on you and control visibility and access at a higher level of granularity.
Custom Control: The Eclipse / Netbeans build always builds JAR files. With custom build mechanisms, you could build your own custom (company-internal) archive with extra metadata information, if you so wish.
Plugins: There are a variety of plugins that come with build tools which can do various things during build. From something basic like generating Javadocs to something more non-trivial like running tests and getting code coverage, static analysis, generation of reports, etc.
Transport: Some build systems also manage transport of archives - from a development system to a deployment or production system. So, you can configure transport routes, schedules and such.
Take a look at some continuous integration servers like CruiseControl or Hudson. Also, the features page of Maven provides some insight into what you want to know.
On top of all the other answers. The primary reason I keep my projects buildable without being forced to use NetBeans or Eclipse is that it makes it so much easier to setup automated (and continuous) builds.
It would be rather complicated (in comparison) to set up a server that somehow starts eclipse, updates the source from the repository, build it all, sends a mail with the result and copies the output to somewhere on a disk where the last 50 builds are stored.
If you are a single developer or a very small group, it can seem that a build system is just an overhead. As the number of developers increases though it quickly becomes difficult to track all changes and ensure developers are keeping in sync. A build system reduces the rate of increase of those overheads as your team grows. Consider the issues of building all the code in Eclipse once you have 100+ developers working on the project.
One compelling reason to have a separate build system is to ensure that what has been delivered to your customers is compiled from a specific version of the code checked into your SCM. This eliminates a whole class of "works on my box" issues and in my opinion this benefit is worth the effort on its own in reduced support time. Isolated builds (say on a CI server) also highlight issues in development, e.g. where partial or breaking changes have been committed, so you have a chance to catch issues early.
A build in an IDE builds whatever happens to be on the box, whereas a standalone build system will produce a reproducible build directly from the SCM. Of course this could be done within an IDE, but AFAIK only by invoking something like Ant or Maven to handle all the build steps.
Then of course there are also the direct benefits of build systems. A modular build system reduces copy-paste issues and handles dependency resolution and other build related issues. This should allow developers to focus on delivering code. Of course every new tool introduces its own issues and the learning curve involved can make it seem that a build system is a needless overhead (just Google I hate Maven to get some idea).
The problem with building from the IDE, is that there are tons of settings affecting the build. When you use a build tool all the settings a condensed in a more or less readable form into a small set of scripts or configuration files. This allows in the ideal case anybody to execute a build with hardly any manual setup.
Without the build tool it might become next to impossible to even compile your code in let's say a year, because you'll have to reverse engineer all the settings
Different features. For example Maven can scan your dependencies and go download them, and their dependencies so you don't have to. For even a medium sized project there may be a very large number of dependencies. I don't think Eclipse can do that.
#anonymous,
Why do you I assume that me, a member
of your team, is using an IDE all the
time? I might want to build the code
on a headless build server, is that
ok?
Would you also deny me the right of
using a continuous integration
engine?
May I fetch dependencies from a central repository please? How can I do that?
Would you tie me to a specific IDE? I can't run Eclipse easily on my very old laptop, but I'll buy a new one.
Maybe I should also uninstall subversion and use patches or just zip folders on a sftp/ftp/Samba share.
The build tools allow you to do a build automatically, without human invention, which is essential if you have a code base being able to build many applications (like we do).
We want to be certain that each and everyone of our applications can build correctly after any code base changes. The best way to check that is to let a computer do it automatically using a Continouos integration tool. We just check in code, and the CI server picks up there is a change and rebuilds all modules influenced by that change. If anything breaks the responsible person is mailed directly.
It is extremely handy being able to automate things.
To expand on Jens Schauder's answer, a lot of those build options end up in some sort of .project file. One of the evils of Eclipse is that they store absolute path names in all of it's project files, so you can't copy a project file from one machine to another, which might have its workspace in a different directory.
The strongest reason for me, is automated builds.
IDEs just work on a higher abstraction layer.
NetBeans nativly uses Ant as its underlying build tool and recently can directly open maven projects in NetBeans. Hence, your typical NetBeans project can be compiled with ant and your maven project already is a NetBeans project.
As with every GUI vs CLI discussion, IDEs seem easier for beginners but once you get the idea it becomes cumbersome to do complex things.
Changing the configuration with an IDE means clicking somewhere which is easy for basic things but for complex stuff you need to find the right place to click. Furthermore IDEs seem to hide the importent information. Clicking a button to add a library is easy but you may still not know where the library is, etc.
In contrast, using a CLI isn't easy to start with but becomes quickly easy. It allows to do complex things more easily.
Using Ant or Maven means that every one can choose his/her own IDE to work one the code. Telling someone to install IDE X to compile it is much more overhead than telling "run <build command> in your shell". And of course your can't explain the former to an external tool.
To sum up, the IDE uses a build tool itself. In case of NetBeans Ant (or Maven) is used so you can get all the advantages and disadvantages of those. Eclipse uses its own thing (as far as I know) but also can integrate ant scripts.
As for the build tools themselves Maven is significantly different from Ant. It can download specified dependencies up to the point of downloading a web server to run your project.
In all projects, developers will often manually invoke the Build process.but it is not Suitable for large Projects, Where it is very difficult to keep track of what needs to be built, in what sequence and what dependencies there are in the building process.Hence we Use Build Tools for Our Projects.
Build Tools Done varieties of the task in the Application which will do by the Developer in their daily life.
They are
1.Downloading dependencies.
2.Compiling source code into binary code.
3.Packaging that binary code.
4.Running tests.
5.Deployment to production systems.
We're starting a project written in Java in a company which works purely on MS technologies. Microsoft Team System is used as source control tool. A question is whether we should try to integrate Eclipse with MTS (which makes sense from the top level as there would be still a single repository for the company) or we should try to setup another source control tool - most likely Subversion (which makes sense from developers perspective)?
Anyone tried to marry Team System with Java projects? Does it makes any sense?
You can use Team Foundation Server with Eclipse with Teamprise.
As for whether it makes sense or not depends on the environment. If you are one of many projects, just one that happens to be Java, it does not make sense to reinvent the wheel and implement SVN, unless the business is making a clean deliniation between Java projects and MS projects ... and realizing they have two places to get metrics for projects, which can be nasty.
I would vote on TFS, personally, as there is already an investment in TFS.
I work on a project that uses eclipse and teamprise to use TFS with java. While the experience isn't perfect, it does work fairly well.
Since your company already has an investment in TFS I would stick with that if you and your team have comfort with TFS as a version control system. However, if you are comfortable with subversion and not with TFS, then I say just make the switch to subverison and you won't look back.
My team is in a similar situation...our company has recently standardized on TFS for source control, and we are a Java group (with many other teams in my company being Microsoft...thus the decision to go with TFS). We are migrating from VSS, so we're actually pretty happy to get to a more modern system (although I would have preferred SVN).
We use IntelliJ IDEA, and with version 8.1 they now have integrated TFS support. So far it seems to be working quite well. We also use Hudson for our continuous integration server and there is a nice TFS plugin for that, too. From our Ant scripts we are using the free Teamprise Ant Tasks when we need to access TFS.
One thing the might be helpful if you end up using tfs (but not teamprise) is the Team Foundation Power Tools 2008 adds Window Explorer extension support (although I wish it has ‘get specific version’ as a menu option)
http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx
From the above link...
"Windows Shell Extension - Allows core version control operations within Windows Explorer without using Team Explorer."
It's free now (after March 2012).
Microsoft.com; Download