Here at work we are using JIRA for bug/issue tracking, most of the developers also use Eclipse and everyone is using Subversion (TortoiseSVN).
I was digging through one of the SVN books and came across a bugtraq property. A bit of Googling turned me onto a great tutorial by Mark Phippard (project lead for Subclipse):
Once in awhile I run into working copy folders from Subversion that I know longer want under version control. I want to “unversion” them. Usually I do some kind of find and delete on all the .svn related folders but there is an easier way if you have TortoiseSVN installed.
You should be familiar with the “Export” command. This will make a copy of the files in a new location without all those pesky .svn folders. If you want to ‘unversion’ something but don’t want a copy – simply do an “export” and when Tortoise asks for the “folder to export to” simply select the same folder your working copy is in! Tortoise will proceed to remove all the .svn folders.
I’m curious how others have setup their repositories:
The Subversion book goes into this a bit – and mentions a few pros and cons of each method but I was curious what people were actually doing.
Right now we are ‘One project per repository’. There were a few reasons for making that decision but now we are re-evaluating and considering moving to a single repository for everything. I’m curious if anyone is currently doing that and having issues? Anyone have an alternate setup?
I’ve recently inherited several projects. Luckily they were already under version control but the directory structure wasn’t using our normal ’standard’. After digging into the awesome TortoiseSVN help file (recommended reading!) I learned a few new tricks:
Fixing Ignored Files
We’ve all run into this one before – you have a file somone mistakenly commited (.log files in my case). From the TortoiseSVN help:
If the files are already in the repository, you have to do a little more work.
- Hold the Shift key to get the extended context menu and use TortoiseSVN > Delete (keep local) to mark the file/folder for deletion from the repository without losing the local copy.
- TortoiseSVN > Commit the parent folder.
- Add the file/folder to the ignore list so you don’t get into the same trouble again.
Moving Files within the Repository
I’ve also got some folders scattered around the repository containing documentation. Ideally these should all live under our /doc directory. But how to move these without loosing their history? Again – from the TortoiseSVN help:
The easiest way to copy files and folders from within a working copy is to use the right-drag menu. When you right-drag a file or folder from one working copy to another, or even within the same folder, a context menu appears when you release the mouse.
Every time I dig into the TortoiseSVN help I learn something new!
Subversion 1.5 is out. For those of us who haven’t moved to GIT yet… SVN 1.5 brings a load of new stuff:
And a host of other things! I’m sure Tortoise and the other clients will be updated soon as well.
We have a standard directory structure for each of our projects:
Testing contains our Selenium scripts (and in the future - unit testing scripts). Build contains our Ant scripts.
At the office I'm in charge of setting up new SVN repositories and one of the things I've done to speed up setting up new projects is to create a 'template' project directory. This contains all the folders listed above along with some default buildfile and testing scripts.
I first created this layout in a new repository. I then added our standard buildfiles and testing suite files. I then created a SVN dumpfile using the svnadmin dump command. You end up with a dumpfile containing the contents of your repository.
Now when I create a new project I simple create the new project's repository, and then use the svnadmin load command to import my 'default' dumpfile contents.
Now when the first person checks out the project - they already have the required directory structure, buildfiles and testing templates.
Someone was asking on the CFEclipse mailing list about how to setup a SVN project in CFEclipse. I started typing up an email reply but thought a blog post with pictures might make more sense.
This tutorial assumes you have the following installed:
First open CFEclipse and open the SVN Repository view.
Window > Show View > SVN Repository
Next click on the Add New Repository button.
Enter the URL of you remote repository and click Finish. I usually enter the root URL so I can access anything within the repository. Your remote repository should now be visible in the SVN Repository view.
If you need to add existing local project files to your repository you can do that at this point by creating a directory within your repository and doing an import:
Now expand the repository and locate the directory you wish to checkout:
:
You should be able to leave the defaults selected and click Finish. We will checkout our project using the New Project Wizard and we will checkout the HEAD revision.
When prompted for a Wizard - select:
CFEclipse > CFML Project
Click next and enter your project name and select your location and click Finish:
Your CFEclipse perspective should open to your new project. You should see the standard SVN icons letting you know these files are under version control:
And you can now manage these files in Subversion via the Team menu:
Have you used svn:externals yet? From the SVN book online:
Sometimes it is useful to construct a working copy that is made out of a number of different checkouts. For example, you may want different subdirectories to come from different locations in a repository, or perhaps from different repositories altogether. You could certainly setup such a scenario by hand—using svn checkout to create the sort of nested working copy structure you are trying to achieve. But if this layout is important for everyone who uses your repository, every other user will need to perform the same checkout operations that you did.
Fortunately, Subversion provides support for externals definitions. An externals definition is a mapping of a local directory to the URL—and possibly a particular revision—of a versioned resource.
At work - I have the following setup in Subversion:
While I could checkout /trunk and setup my webserver to point to the /coldfusion directory this wouldn't be exactly the same as my production environment. I need to checkout the /coldfusion directory. This leaves my build, testing and other directories left out. By using svn:externals I can grab those directories as well during checkout.
Note: Be aware there are several issues with svn:externals regarding update/commits of code included in the external directories. Please read the related documents online (and if you have Tortoise SVN installed check out the section related to svn:externals in their excellent HELP section - it is listed under the "How Do I..." section in "Include a common sub-project").
Now lets see how to setup svn:externals using CFEclipse. First if you haven't already - we'll checkout a copy of our project. Here I'm checking out a my /coldfusion subdirectory which contains my project code.
Here is the project in the CFEclipse Navigator view. You can see the path reflected (core/trunk/coldfusion). Now I need to add the other directories (build, testing, etc)
Now we can right click on the top level of our project - select Team > Set Property.
The svn property dialog will appear. For the property name select svn:externals. Make sure "Enter a text property" is selected and enter the following (alter this path to match what you want to include):
The svn:property consists of two items - one the name - here I'm using 'oracle' and the full path to the repo. We can define several of these so we'll end up with:
Click OK and you will return to the Navigator view and your svn icon will have changed to let you know things are out of sync. Commit then Update your project (Team > Commit / Update) and you should now see your external directories!
Again please note there are some things to be aware of regarding updating and commiting changes in the external directories. From the Tortoise SVN Help:
Each time you update your main working copy, you will also receive the latest version of all external projects.
If the external project is in the same repository, any changes you make there there will be included in the commit list when you commit your main project.
If the external project is in a different repository, any changes you make to the external project will be notified when you commit the main project, but you have to commit those external changes separately.
While in this example I am using CFEclipse and Subclipse you should be able to follow similar steps using any tool that works with Subversion.
