HI I have and android project A, I have been working on it, and also a friend of mine has been working on it, so now I have 2 projects A-Mine and A-Friend (I have nor svn, cvs nor git). Is there a way to get a diff of or to merge them, using ecplise or tortoise or anything (windows based)
Thnak u very much best regards Ignacio.
Now's a great chance to set up source control! Commit your version into source control, have your friend check it out, create a new branch and recursively copy all his files into it. Then just use the tools provided by your source control software of choice to merge those changes into the main branch. Done!
As I thought my friends there is always another way, Turns out ecplise won't allow you to open twice same project in the same workspace, but you can very well match up files and folders with simple windows copy + paste, so what is what you do? Yo open one project in eclipse and paste the renamed folders of the second project. the you can use Eclipses Compare With tool, to match up all files in a certain directory.
Clean, easy and fast
Related
I use 2 machines for development, Windows 8 desktop and a Macbook for when I'm away from my desk. I use dropbox to sync my development files between 2 machines. This works pretty well, except for one thing: the SDK path must be updated every time (http://screencast.com/t/XKnqUjiBn)
Is there a work around of some sort for this?
Don't share the local.properties file between machines; that's the file that contains the SDK path, and as its filename indicates, it's supposed to be local to an individual machine.
I suggest that you take a look at a GIT source control (if you haven't done that previously). It is the way better way to manage projects than dropbox sync.
There are 2 very good options for you:
GitHub - free for open source projects, paid for private repositories (paid per repository)
BitBucket - free for private repos too (paid per user)
AndroidStudio (which I suggest for Android projects unless you are working with NDK) has a really good support for importing projects to GIT via GUI. So it helps you a bit if you are not familiar with console stuff. But it is easy with console too. Check out this github tutorial for beginners https://try.github.io/levels/1/challenges/1
With GIT the problem that you are trying to solve is simple just put a file name that you dont want to share into you gitignore file. You can find android preset gitignore files online on sites like gitignore.io.
Good luck.
I've read and read and I'm still confused on the concept as described in the title: how do I maintain sync'd code between two computers, using Egit w/ BitBucket, when an Android library project like ActionBarSherlock is required?
I guess things got complicated for me when I started thinking about Eclipse workspaces vs. local git files. I am now very confused on the most efficient way to be syncing between two computers. I am able to do it now, but it's very cumbersome and ALWAYS the project-properties is incorrect about the path to the ActionBarSherlock library.
TL;DR - This being said, what is the high level concept for easily pushing and pulling code from BitBucket without dependencies getting broken in the process?
Also, should I have a full copy of my project in my workspace AND in the local git directories? I believe I should as one mirrors the other? Or should I only have 1 physical set of files, in the local git directories, which is logically referenced to from Eclipse (as opposed to having the physical files copied to the workspace itself).
Thank you for clearing this up,
Ryan
Figured it out: Here's what you do. Set up the development environment to use the same workspace path on both development machines. I switched mine to 'C:\Development\Android\workspace'.
Next, I imported ActionBarSherlock into the workspace I just created (make sure you copy the files into the workspace), do this on both development computers.
Now, ensure the path to the local Git files is the same on both machines, it needs to be the same as the path to your library project will be relative, and not fixed (../../ instead of C:/...). In this case, I'm using 'C:/Development/Git' for the local Git directory.
Next, import the Git project by cloning it from URI using the BitBucket URL for the project you set up. Right click on the project you just cloned, select Properties > Android, at the bottom of the Android tab, add ActionBarSherlock as a new library.
Commit and push the changes to the project.properties file. Voila! If both computers use the same paths, your library project will work as it should when updating your Gits!
I use two computer for coding. My desktop pc and the notebook. I sync the two computers with dropbox. How can I import/load a project on each of this two computers? The project base folder is different on each computer. When I try to load/import a project which is created on the other computer it loads the project but I got a error with a wrong path.
"Gradle "Test2Project" project refresh failed:
Could not fetch model of type "IdeaProject" using Gradle distribution "http://services.gradle.org/distributions/gradle-1.6.zip".
Project directory "C:\Users\thomas\AndroidStudioProjects\Test2Project" does not exist."
The wrong pfad is the right pfad on the other computer. How can I import Android Studio projects so that it works even on another computer with a different folder structure?
Like the others i agree, that using a VCS would be the best solution. Even though you can try to filter all android studio related files (like *.iml, .idea folder and local.properties). I don't know if you can do this with dropbox or if you need some kind of 3rd software.
After that you should be able to make source code changes on both computers without greater problems. (You may have to declare project dependencies changes for the android studio twice)
Builds depending on the build.gradle files should work to. But again: using a VCS is the better way to go.
Go for git, you can use bitbucket.com as a free remote repository.
This is a problem I have ran into when trying to store Android projects in a Dropbox folder. What happens is that Machine 1's IDE is mapping system resources (like the SDK) as being in that machine's filesystem. When you go to Machine 2, everything will work EXCEPT for what you expect--because the SDK will probably be in a different spot!
One way to get around this is to use your VCS (dropbox, git, whatever) as a repository for JUST your source files, and then have a local project created on each machine that reads from the Dropbox folder. This requires two separate projects that are mapped differently, but that have the same source folder.
I discovered this problem when I tried to load up an Android project on a new install on a Mac machine:
Do you see what's happening there? My Mac Android Studio is saying, "Hey, I don't see where "C:\Android\SDK is, but I do see that you have an Android SDK in a different folder, so I'm going to update your project files to reflect the actual location of the SDK."
In my opinion, the only way around this is to create your project on both machines, and version control your source and assets folder. If you don't create the project separately on each machine and use VCS for just the source and assets, the only way to get around build and filepath errors is to store your SDK in the same folder on each machine. This worked for me when I was building on a Windows desktop and Windows laptop, but no longer works for me since I am using a Macbook Pro.
I know this was questioned about 4 years ago, but this is up to now still an issue. Using a VCS seems like a good solution, but for me it is simply more overhead than i want to have. I also use Dropbox to synchronize my folders and the history they provide is for my private programming needs good enough. So i think, it would be good, if android studio simply uses relative paths.
I know it needs some system paths and it does a good job in looking at the local.properties and setting it to the correct place when the project is loaded.
The main problem with using Dropbox are the build-directories. There are many many references to fully qualified paths in the files within these directories. So my solution was to exclude the build-directories from Dropbox-synchronisation.
When you work at your laptop, build the app, create new files, change files or delete files, the build on your pc will be completely outdated when you switch back to it. but android studio will recognize this and do a fresh build when you start your project for the first time after working on the laptop.
so the biggest problem at this point is the file local.properties and this is handled correctly by android studio. it may be a good idea (or a really bad one, i don't know the drawbacks) when the build system wouldn't write fully qualified paths in the files within the build directory.
But up to now this is my solution for using Dropbox and not using a VCS:
exclude build-paths from Dropbox synchronisation
i hope this helps somebody.
Hey guys simple question here. Whats the best way to back up an android project? I use eclipse. I'm fairly new and not sure what I need to back it up. Do I need just the project or do I need the meta data also? Thanks guys
If I'm understanding you correctly you want to make a backup of your project? If you've never used version control before, now would be a great time to start! Version control will not only provide you with what you're looking for but many other great features. There's plenty of different SCM's available for you to choose froml; Git, SVN, Mercurial and so on.
Otherwise if all you want is to copy the project to another location, open your eclipse workspace folder (the directory you defined when you first started eclipse) and copy the project directory from there. Or do as MarchingHome suggests.
I always directly copy the entire folder of the project in the eclipse workspace.
You can import that later in eclipse via File --> Import --> General --> Existing project into workspace.
You can there select the folder and everything will be restored.
Hope this helps.
As long as you work alone and on always the same machine, you can simply backup the entire project folder with the help of a version control system like git. This will help you keep track of all the changes you make and lets you undo any code changes. You can use github as a reliable remove service. If you aren't familiar with it yet, then it might take some reading to get into, but afterwards you life will be much easier.
You need the metadata. There are a few files in the top level project directory when you use eclipse: .cproject (this might only be if you use CDT plugin), .project and sometimes a .settings directory. Basically, you need all the dot files/dirs. You can just zip up the directory and that should be enough.
That said, if you try and open that project and the paths have changed, you'll probably get errors. Same for if you're missing vital plugins used by your project.
What you should be doing is using some sort of revision control. Try git or mercurial. Eclipse has plugins for them as well.
I have a bunch of code in Surround SCM, which I would like to get into a workspace in Eclipse. I will need to be able to work off of two branches. One for bug fixes, and one for new features, which can then be merged into my main branch. What is the best way to do this?
Disclaimer: I work for Seapine but I wasn't involved with anything to do with Eclipse.
What we do here internally is have a separate Java project for each branch in a single Eclipse workspace. To do so create a workspace somewhere and do:
File->New Project...->Java Project
This brings up the new project dialog. You can then point the project at the existing source path for the first branch, in my case the mainline branch, using the "Create project existing source" radio. I think I might have an older version of Eclipse installed but it should be the same or similar in new ones.
Clicking Next will take you to the next screen.
Here you can set up specific settings for this branch, like packages to exclude or things like that.
Click Finish and your project will be set up. Just repeat the same steps for a different branch using a different disk location.
Once you make changes to your branch code you can just check it into Surround SCM, promote it to the mainline, then do a get bring down the changes locally to your other directory.