I've found myself in the odd position of being a TA for a software engineering class wherein I routinely have to check out each student's project from a Subversion repository. What this currently entails is manually adding around 100 repositories to Eclipse every two weeks.
All of the repository URLs are of the same form, something along the lines of domain/svn/teamXprojectY where X and Y are numbers in a given range. It would be trivial to output these URLs to a text file or something along those lines, but is there any way to automate adding these repositories to Subclipse? I've searched online as well as in the Preferences and menu options for Subclipse and can't find anything that might help me.
If anybody has any idea how to do this, it would be much appreciated. Thanks!
You can make an Eclipse "Team Project Set" file that lists all the projects you want to checkout. You then just have to import this file and it will add all the repositories and checkout out the projects.
The easiest way to see the format of the file is to take a workspace with a few sample projects checked out via Subclipse in it and do File > Export > Team Project Set and choose those projects.
You can then edit this file with any editor and later on do File > Import > Team Project Set.
If you are willing to serve your repositories via Apache, then another option is to install CollabNet Subversion Edge on your server and CollabNet Desktop in Eclipse (all free). With this combination, you just enter the URL of your Subversion Edge server into the CollabNet Sites view and all of the repositories on the server are accessible without entering their URL's.
http://www.open.collab.net/products/subversion/whatsnew.html
There are other reasons using Subversion Edge might make your life easier. The next version due in a week has a full REST API so you could automate managing users and repositories via scripts. Even without that, it gives you a full web UI to manage the server and repositories.
Related
I'm developing a QNX app (thus I'm using an old version of Eclipse-CDT C++ etc.). Up until now I've been checking out with TFS and then importing the project files to the workspace via Import->General->ExistingProject; this means I can build/debug etc, but I've only had TFS functionality available via TeamExplorer from the TFS perspective. If I import the same projects to a different workspace via Import->Team->TFS then I have extra TEE functionality but I can't build/debug etc.
So, what's the recommended way to do this? I'd like both functionalities.
Edit ---
I imported each project one-at-a-time via Import->Team->TFS and it worked.
I'm not sure why importing from TFS doesn't detect that project's nature correctly. (Are you not checking in .project files? Are you using Maven?)
Regardless, if you want to go the route of importing an existing project from disk, just go to the Team menu, select Share, then select TFS. It should detect your working folder mappings and simply set TFS as the source control provider for that project, which should give you all the TFS bindings from within editors and views.
For a number of good reasons (I think), I find myself wanting to use the SVN command line client rather than the plugin for particular Eclipse-based Android project, and I'd like to verify some assumptions and observations I've made so far:
Don't check-in derivative folders such as: bin, gen, obj, and libs
Do check in source folders such as: assets, jni, res, and src
Do check in .project and .cproject configuration files
This leaves the question of what to do with .classpaths and .settings? Although I've seen some recommend that I don't, I currently do check in .classpaths but not .settings (just discovered it - I'm an Eclipse noob). Any advice from people who've found themselves needing to use SVN outside of Eclipse?
If you are using similar environments (like similar Windows 7 clients where everything is installed and organized in a similar fashion) you can add project specific settings (.classpath, .settings) to version control too. However if your project is checked out in different OS'es, then most probably you would want to keep them out of versioın control.
Eclipse can guide you to what to do. Import the project into SVN by using Eclipse plugin. Then you can switch to the command line tool on prepared repository.
I have been working with the same Subversion working copy as a sub-directory of my local server's htdocs folder for months now. I was working in PHPDesigner7 and managing my repository with TortiseSVN. As I am the only one working, I just commit and keep working without any real need for multiple checkouts or updates.
I recently moved from PHPDesigner7 to Eclipse for my every day IDE. I have created a project and used my working copy root as the location. I have been writing all my code in eclipse for about six weeks now, and it seems like it would be much easier to do SVN operations within the IDE. I want to start integrating SVN into my Eclipse workflow, but I want to keep my working copy in the same place it has been. There are a lot of files like Adobe Bridge index files and Docblox configuration files that I do not keep under source control, but are still important to my tools. If I create a new checkout these files will not be present. I also like being able to do local server testing directly from my working copy.
How can I use my existing working copy from within the Eclipse IDE? I have installed Subclipse, but I set my eclipse project up before I decided to try switching SVN management to the IDE. Is it as simple as making my workspace the same as the working copy? I have just been using the Eclipse default workspace. Would I be better off with a fresh Eclipse project? Are there any caveats I need to be aware of when moving from Tortise to Subclipse? I especially wonder if Subclipse does many small commit operations, or if I can continue making fewer heavily commented larger commits? Does anyone prefer the subversive plugin? If so why?
The root directory of your eclipse project should be the root of your working copy. Then you just have to right-click on the project and choose Team - Share Project, and follow the tutorial. At some point Eclipse will ask you if you want to keep the existing .svn files or not. Just choose to keep them.
The workflow in Eclipse is exactly the same as with any other SVN client. You update and commit when you want to. And you may also continue using TortoiseSVN to perform your SVN operations if you prefer. You'll just have to refresh your eclipse project after each operation.
All,
I have a 20 member dev team working on a development project.
To provide greater control we have created a workspace with necessary projects and configurations (like project preferences, set-ups etc) in IBM RAD.
The idea is to have the pre-configured project in subversion so that when the dev team members checkout the project they get a complete workspace, so that they do not have to configure setups them selves.
However the problem is everytime someone checks out the workspace IBM RAD will also edit the .metadata (and some other folders and properties file) folder that has been checked in.
Idea is the developer should not have to change anything except the source code folders or application specific files.
I think many other teams might have faced situations like this.
Can anybody provide the best practices/process/references on how this is done in development projects?
Thanks
I think svn ignore will solve your problem.
check http://svnbook.red-bean.com/en/1.1/ch07s02.html
The svn:ignore property contains a
list of file patterns which certain
Subversion operations will ignore.
Perhaps the most commonly used special
property, it works in conjunction with
the global-ignores run-time
configuration option (see the section
called “Config”) to filter unversioned
files and directories out of commands
svn status, svn add, and svn import.
You cannot stop IBM RAD from updating .metadata folder and Eclipse doesn't support splitting workspace folder as it does for the configuration folder.
The best solution would be to setup your build scripts to be able to setup your workspace based on some .zip file(s), where you've captured the required settings for the workspace. This will give the closest thing to automatic workspace setup without having to deal constantly with changed files in .svn.
We are migrating from a Server 2000 machine to a Server 2008. I have already found great instructions for packing up my repository and moving it to the new machine.
My development tool is Eclipse. My goal is to not remove all of my projects and check them all back out. That will be a huge pain.
What is the easiest way to point Eclipse over to the new server without removing my existing projects?
The hard method looks to be running some kind of a script that edits about 9 billion CVS\Root files and updates the ip address.
Change the repo settings within Eclipse from the CVS Repositories perspective. Right-click on your repository definitions, change the settings to the new server.
When you save the settings, Eclipse will ask you to confirm that you're changing the server, and then it will update all the required metatdata files.