I just created a brand new local subversion repository (c:\svnrepo) with the following steps:
mkdir c:\svnrepo
Opened c: in Explorer, right-clicked \svnrepo, and selected TortiseSVN->Create Repository Here
Had TortiseSVN create the default directories.
Now... I have two existing projects that I want to move into the repository. Let's call them "mylib" and "myapp". If it makes things easier, I can create a separate repo for each project instead of dumping both of them into different subdirectories of one big repo.
mylib is an IntelliJ project. It's a Java library, and currently inhabits c:\src\mylib
myapp is an Android Studio project. It's an Android app, and currently inhabits c:\src\myapp
Now is the point where I'm struggling. I used to know how to do this with my eyes closed, but it's been a few years since the last time I've had to create my own local Subversion repo from scratch, and I've basically forgotten how to do it. Plus, the last time I did it, I was using Netbeans (Java), Eclipse (Android), and SyncroSVN.
I vaguely remember that the procedure goes something like this:
Import the project (say, c:\src\mylib) into the local Subversion repo, add all the files, and commit them... but first, configure subversion to exclude all the files and directories that shouldn't be under VCS. I'm pretty sure there's a convenient way to do this in both IntelliJ 14 and Android Studio... but I don't know what it is (the last time I did anything like this, I was using Eclipse and SyncroSVN). At this point, I'm not even sure which directories and extensions SHOULD be excluded, because every online tutorial I find seems to have a different opinion (compounded by the radical changes Android Studio has made to its project directory structure with seemingly every single major new release).
Move c:\src\mylib and c:\src\myapp to c:\backup for safekeeping, then from c:\src, check out mylib and myapp from the Subversion repo. Once again, I'm pretty sure IntelliJ 14 and Android Studio both have a workflow to do this all in a single step, but I don't know what it is.
In theory, after I've done steps 1 and 2, I should be able to reopen the projects using IntelliJ or Android Studio, and the only difference is that they should both now be aware that the projects are under version control & somehow visually indicate files that differ from the repository copies.
What's the current proper way to do the steps above to get my two projects under Subversion control?
I have the following installed:
svn commandline client
TortiseSVN
SyncroSVN
IntelliJ 14.1.5 (yeah, it's about a year and a half behind the current release... my subscription lapsed, so I'm stuck with the version I had last May).
Android Studio 2.1.2
Just to be clear, I remember that there are two ways to organize a Subversion repo... either as a single monolithic project where the actual Java/Android projects are subdirectories of trunk, tags, and branches... or as separate repositories with one project apiece (each of which has its own trunk, tags, and branches). Either structure is fine with me. I just feel like I'm going in circles right now & desperately need a few nudges in the right direction.
First of all, install Subversion server on your machine. You could use http(s) URLs instead of awkward file:// access schema.
In any case, here are the steps that should work in Android Studio and IDEA both:
Open your project.
Select VCS | Enable version control integration.
Select VCS | Import into Version Control | Share Project (Subversion).
For Repository Location enter file:///C:/svnrepo/ or https://svn.example.com/svnrepo/ and select the project structure you need.
Select Share.
Related
I am trying to contribute to my first open source project but after forking and cloning from the repo, all files are marked as an error.
Sample error
This is after selecting a source folder.
Current project source
Under package it says: package name does not correspond to filepath
... but I have this
misnamed packages?
Android studio isn't picking up those libraries.
IME there are 2 ways of importing these (I have only had success with the first):
1) copy the source parallel to your own (ie example.com)
2a) include the jar in a libs folder and tell AS to look out for it. (right click will typically provide a good option that I can't recall)
2b) because Android can struggle (ie I couldn't do it, though inroads may have been made since) with importing jars, you may need to use AAR's (android library packages, Android Archive Library (aar) vs standard jar)
However, because this is an open source project, this should all be handled auto-magically for you via the gradle scripts included in the distro.
I somehow imported an Android project to my Subversion SVN using an option "Import into Subversion" and "Checkout from Version Control". I realized that my import is not how I wanted. Probably I should have used "Share Project (Subversion)" in the first place, but now there's of course no "share" option anymore.
Is there any repository metadata that needs to be deleted on order to make "share" option available again?
Tried it with Settings -> Version Control and removed directory but that didn't help.
Is there any repository metadata that needs to be deleted on order to
make "share" option available again?
Yes, there is. SVN places hidden .svn directory at the root of working copy. I guess that you should remove it and reopen the project to make 'Share' command available again. You could also checkout a new working copy of the imported/shared project.
Frankly speaking, those 'Import' and 'Share' commands in the IDE are kind of confusing. When you 'Import' a project, you simply add it to the remote SVN repository and commit this change. Importing does not make your local project a SVN working copy and does not enable any version-control capabilities. You should checkout a working copy of the project after importing it. On the other hand, when you 'Share' a project, you import it to remote Subversion repository and you also make your local copy to be SVN working copy enabling version-control capabilities.
Android Studio is based on IntelliJ IDEA. Therefore IDEA's documentation should also work for Android Studio. Read these help topics
Importing a Local Directory to Subversion Repository
Sharing Directory
I'm getting myself into a bit of a tiz here.
I want to copy an Android Studio development project onto an Apple Macbook for remote working. Simple. (?)
The project uses Mercurial for code control. I have only placed the actual src files (including 'build.gradle' and the manifest etc.) under code control (adding .idea, build, .gradle et al seemed a bit over the top).
I have tried copying the PROJECT file lock, stock and barrel across to the Mac, but since this is not a proper "clone" of the Mercurial repo, I am worried that merging will not work properly and I'll damage both copies of the project.
I have tried 'cloning' the repository into an empty PROJECT directory on the Mac and then starting Android Studio, but this loaded revision 1 of the project with none of the build variants. Even upgrading to the latest version, the project won't build properly (probably because of the files that aren't under code control).
So... what is the simple way of cloning (for want of a better word) a project onto a different computer and then being able to use Mercurial to keep future code changes in sync?
Should I commit everything in the project directory into to Mercurial and try cloning and copying the repository again?
Or is there a smart way of setting up Mercurial correctly when I have copied the PROJECT directory?
Or is a moderator just going to tell me to f off and ask the Software Engineering lot? :)
Ok. I've got this working satisfactorily now. My solution was a hybrid between the two options. A bit of a hack, but I can now push and pull changes between the two repos which is what I wanted to achieve.
I copied the complete PROJECT directory onto the Macbook
I cloned the Mercurial repo to a separate temporary directory (using TortoiseHG).
I deleted the .hg subdirectory that was copied onto the Macbook, and replaced it with the .hg from the temporary directory.
I then updated the PROJECT directory from the Mercurial clone in order to get the repo in sync (again using TortoiseHG).
I don't believe this the the "correct" way of achieving a working copy of a Mercurial/Android Studio project but it's working for me.
We are trying to figure a way to setup TFS for our needs. We have, let's say,
Project A, Project B and Framework, a project shared by many projects.
Framework
Project A
- Framework
Project B
- Framework
If the Framework is modified, we want to make sure that every project that
use it has the last version.
We first thought about sharing the Framework by adding it to project A and B using "Add as link"
in Visual Studio, but this would also modify all branches, which is not good. So we thought
about compiling Framework into a DLL and include a copy of this DLL into each project. The
drawback is that the DLL has to be updated manually for each project.
What is the best way to share a project in TFS?
There is no 'sharing' as such in TFS as-in the way you could with Visual SourceSafe. You have 3 options
Use branching and merging. You branch Framework into Project A and Project B. If changes are made to the framework, the project teams will have to merge them into their project. If they make changes to Framework in their project then they will have to merge back to Framework to allow other projects to consume the changes.
Use Workspace Mappings. Essentially this is setting up sharing. When I do a get on my ProjectA workspace, it would also get the code in Framework to a subdirectory that I can reference in ProjectA. Any changes would be propagated to Framework and all the projects as soon as they did a get latest.
And probably the best solution is to use something like nuget. Your Framework build would package and publish the latest version which would then be consumed by the Projects. You could choose to stick with a version or pull the latest at build time.
TFVC Gems - should cover the first 2 options
Dependency Management with NuGet.pdf - talks about option 3
I'm assuming that we're talking about a .NET set-up, if not then this might not be relevant.
I believe that if you have a reference to the framework project (rather than the compiled DLL), then every time you recompile your projects, you will pick up the latest version of Framework (obviously, this is dependant on your branching structure).
Another thing to consider, if the above doesn't work, is to use a build to recompile the dependencies first.
I just made a clean install, as I do every year, of my linux system (ubuntu) on my notebook.
I just wanted to open-up eclipse from my (old) workspace, where all my code from the past 12 months is - but eclipse doesn't show a single package!
My assumption is that I used an older version of eclipse up until yesterday before the clean install, and that the version I installed today is newer, thereby doesn't recognize my worksapce(s!). Is this assumption correct? if so, Does anyone know how I can figure out which version of Eclipse I was using when working on the old Workspace, so that I can download that exact same version again?
The absolut worst-case scenario would be to c/p all classes and packages manually into the new eclipse, but it's over a 1000 classes - so that might be too time-consumming.
An help would be greatly appreciated, since there actually are 2 projects from work in those workspaces... ^^
Well, after Downloading Eclipse Mars, I found a solution. Although switching workspaces, or even importing the old workspaces didn't work, I found out that if I started eclipse from the old workspace, even though package explorer would stay empty, it would suffice to define a new java project with the exact same name of one of the projects inside the old workspace, for eclipse to instantly load-up the docs contents.
This not as much a solution, then a work-around... but still, fixed the problem!