I have a project on codeplex and I'm trying to reorganise the tree structure so it makes a bit more sense and is easier to work with.
This is my current layout:
TopLevel
|-->src
|--->ProjectA //This is where all the files are held
|-->Core //plus three more folders
|-->MyProject.Core
|--->trunk
|-->src // I want to move all the folders and files in ProjectA into here
So I want to move all folders and files under ProjectA to ProjectA.Core/Trunk/src.
I checkout the whole source tree and right-clicked dragged the folders under ProjectA folder and selected "move versioned files here" into the src folder, that marked the folders in Project for deletion but the new files in src still had the green tick next to them and not the blue plus button.
After I commited the changes I had a look in the repo browser and saw that the folders hadn't been moved and were still in the ProjectA folder.
How can I move folders and the files in those folders to a different folder in subversion? Without loosing version history.
I'm using TortoiseSVN.
EDIT: Turns out it must have been codeplex, I moved my project to google code and everything works fine.
This type of reorganisation is easy to do with the Subversion command line client, which might be a viable option for you. Here's the commands that would do it (from the TopLevel directory):
svn mv src/ProjectA MyProject.Core/trunk/src/
svn ci -m "relocate ProjectA"
You can also combine both commands into one by using URLs as the source and destination, see the svn mv documentation for details.
I haven't found an easy way to do this sort of thing with TortoiseSVN, so when I need to I just use the command line client to do it.
I don't know what I was thinking when I suggested to export and import the files. I think I've been away from TortoiseSVN too long. I recall that tortoise svn actually has a really easy method of moving whole directories. It's not just obvious... but it's not clear why you can't get the result committed correctly to the repository. Presumably you did commit on the parent of all these folders.
Here's the summary:
You must select the folder and files you wish to move, and after doing so right click on the selection and drag it with the right button to the new location. You will get a context menu asking if you wish to relocate the files in the repository. This retains the history. Now your old files are marked for deletion and your new files should be marked as added. (I've found the status icons to be... not always representative of the true status). Commit this as one commit. I like to be picky and use check for modifications on the root of the checked out files, and then select exactly which changes I want to commit before doing so.
In the case of just moving one folder like this, open a window that is a parent to this folder, and another window that will be the new parent of this folder. Right click and drag all in one motion. I can't believe it takes this much text to describe a simple mouse action.
The standard strategy for dealing with nasty moves is, in the worst case, create all the new directories, move only the files from the old directories to the new directories, and then remove all of the old directories. This should get around almost any problem you encounter, and you can take shortcuts (moving entire directories and or trees) where that does work.
This will preserve history on all files. It will not preserve history on directory creations, but usually this is something you can live with, since you do have history for all of the file moves, which include the old and new directory names.
Related
is there a way to move this folder with Issue Templates to .git ?
i have more diverse stuff to fill this file list with, this one just takes space for no use . and i don't want to extend editors with file hiding functions .
If you have no use for the .github directory, one solution is to simply delete it. You can have a look at this answer to see what it contains. Many of its contents can simply be moved to the project root (or deleted, if you don't need them).
You could theoretically put them in the .git folder, but you would not be able to actually git add them (you'd basically be making the .git folder track itself), so you're losing all the benefits of using git in the first place.
The repository folder I have been working in changed over night. Files that were in the folder are no longer in it, both in svn and the source folder. The attached pictures show what has changed between the days. The small folder 'kettle' is all that is left from the large one (what it use to look like). It looks like this in windows explorer as well. Also, since I had local changes I had no put to version control yet, I do not want to just re-checkout and lose my changes. Any insight to a solution to getting the original state of my folder would be greatly appreciated.
The current state of the folder:
What the folder looked like yesterday:
Looks to me like someone renamed the project folder in the repository. You will need to
back up your changes (project folder into a zip for example) and try to sort out things manually.
Another solution could be creating your own branch that just mirrors the current state of your workspace. But merging the changes back to trunk might be problematic here, too.
Over the last few months, I've been doing some maintenance on a project with many source files. I was recently informed that there is an issue with one of my bug-fixes and I was asked to fix my bug-fix.
However, since there are so many files and folders within the project, I can't remember which one I modified.
Therefore, I would like to be able to search within the root directory of the project for changesets that have affected files within the folder. I'm sure that I could determine which changeset caused the problem by the comments I put on them.
How can I find all TFS changesets that affect at least one file within a specific folder?
If you're interested in viewing the history for a single folder, navigate to that folder in Source Control Explorer, right-click on it and select "View History".
This will show you all the changesets that have affected this folder.
Going to the CVS repository perspective and viewing the files shows them, so they checked in just fine, and doing an update will bring them into the project. It is only the synchronize that is having problems.
I have noticed that, when synchronizing trees that do not contain source files such as *.java files causes the cvs synchronize view to look strange (there is an update to be done but it cannot specify the path). Usually, you would actually want to see what is updated..
So, the solution as per me is to perform a team->update on project root level, or to use another cvs client to make the update. (TortoiseCvs works)
I'm not sure if this is the problem, but do you realize files won't appear in the synchronize view if they are identical to the files in the repository?
I'm in the process of refactoring some code which includes moving folders around, and I would like to regularly merge to keep things current. What is the best way to merge after I've moved folders around in my working copy?
You can move the files around in StarTeam also. Then merge after that.
Whatever you do, make sure you don't delete the files and re-add in StarTeam. You'll lose the file history if you do that.
Moving the files in StarTeam and then updating your project/solution is the cleaner way to go. I would also suggest creating a view label prior to doing anything so you have a definite "roll back" point if things go wrong :)
Folders in StarTeam can be renamed to match the filesystem moves by right clicking the folder and going to Properties. If you created new nesting levels, you will have to create those folders normally. If you moved files between existing folders, you can move those in StarTeam by dragging them from the file window on the right to the new folder on the left. Files can be renamed to match a new name in StarTeam the same way folders are, right click the file and select Properties.
As a fellow StarTeam user, my condolences go out to you.
In an ideal world, you could branch the view and merge back when you are happy with your revisions to avoid breaking the build. However, as you are using StarTeam, I would suggest making small incremental changes to the folder structure and accept that you will probably have a few breakages along the way. It will likely be less time consuming and more intuitive than trying to use the view-merge interface.
The problem is I'm worried about breaking the build in the meantime while I'm moving folders in StarTeam. I suppose the only way to avoid that is to be ready to upload updated project files as soon as I move things around in StarTeam and do it as quickly as possible.