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.
Related
Eg:
parent->1.Test
2. source
I want test folder to move into source, How to move it in github web app? Can previous versions be tracked after moving?
Just move your folder inside the source folder and if your app is already under Git version control, it will track this move as well and before moving things are already tracked in your previous commit.
There is nothing special which you need to take care, we move lots of folder while doing the code-refactor and its a very common scenario.
let me know if you need more information.
I need to checkout files from StarTeam 12.0 into my local folders.
The folder tree on starteam is like :
folder_top
folder_level_1a
subfolder_level_2
subfolder_level_3
folder_level_1b
folder_level_2
folder_level_3
But, after checking out all files in my specified local folder, all files (of folder_top) are located in one folder. All subfolders and their files are not checked out.
Any help would be appreciated.
Selecting your top folder, then selecting Check Out All from the File menu will check out all the files in that folder and descendant folders.
Also, note that clicking the All Descendants button will show all files in descendant folders as well as the selected folder.
Sounds like you might have checked out to a specific location. There is (or at least used to be) an option in the check-out dialog to override the location of the checkout, and in this case all of the files would be placed in that specific location. What you need to do in StarTeam is set your Alternate (not Default) Working Folder for the View, and then all of the files you check out will be put in the relative location based on the folder name. Do not override the working folders at the folder level, because this will cause your folder structure not to be mirrored. If you keep it simple and always set the Alternate Working Folder at the View and nowhere else, all your checkouts should go to the expected location. Don't override in the checkout dialog. Keep in mind, however, that even if you don't override the default working folders at the folder level, someone else on your team might. In those cases you can override their overrides by setting your alternate working folder to the folder name. This is one of the most painful and poorly designed aspects of StarTeam and always has been. Despite years and years of proposed enhancements to fix this, they have done nothing to address these issues. Be vigilant!
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 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.
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.