I'm new to using VisualSVN, and I wanted to know if you can get a specific file that has been added to source control in an upper level directory without have to update the entire directory (through windows explorer). For instance, if a co-worker adds a config file to the root directory of a solution, how do I get that specific file for my machine without getting latest/updating the entire solution folder?
You can do svn export using direct link to file with (e.g. svn export http://svn.example.com/svn/repo1/config.xml). This operation could be done using Tortoise SVN from Windows Explorer context menu. But keep in mind, that svn export is just a way to download file, wtihout any version control on it.
You also can do a sparse checkout (see this answer).
Related
I need share to share certain files between different projects. Thus I have a file structure like so:
D:\shared\
D:\shared\files-shared-by-all-projects-here
D:\project1\
D:\project1\project1-specific-files-here
D:\project1\shared <- directory junction to D:\shared
D:\project2\
D:\project2\project2-specific-files-here
D:\project2\shared <- directory junction to D:\shared
I have setup GIT repos in D:\project1 and D:\project2 My problem is that GIT seems to only track files in non-junctioned (i.e. real directories).
I use Visual Studio 2015 for both projects, and it's Team Explorer would behave very strangely when project has files from "junctioned" directories:
Upon adding a file residing in a directory junction to a project, Team Explorer would only show its parent directory (junction) in the list of changes to commit, not the file itself.
Upon committing all changes (i.e. files have been added), Solution Explorer shows all files as being tracked and checked-in (including those that reside in junctions and were not shown in the list of pending changes after they have been added:
Editing a file which is shown as checked-in and resides in a junction directory will make it appear to be checked-out:
Returning to Team Explorer now, the checked-out file is shown in the list of modified files:
However trying to commit it fails with a message: "An error occurred. Detailed message: No changes; nothing to commit."
Returning to Solution Explorer the changed file for which commit failed is nonetheless shown as checked-in:
Explicitly adding files that reside in the shared directory (i.e. referencing it via D:\project2\shared\some-shared-file) from outside of Visual Studio using Tortoise GIT for example does not work: add fails with a message that it is both a file and a directory.
The above was done with a new test project where frame directory residing in project's root is really a junction.
In my actual projects however the situation is slightly different... If I browse the repo using Tortoise GIT for example it would actually show the shared files residing in junctions as being tracked and checked-in and part of the repo. However as soon as I open the project in Visual Studio, it would show though same files in Solution Explorer and Team Explorer Changes as "pending delete". So is this a VS quirck?
So the bottom line is I just want to know how can I make files residing in directory junctions to be viewed as part of the project on par with regular files, so that they are properly checked out and checked back in and form part of project's (repo's) history?
At present, this is not supported. This is due to a difference in interpretation between junction handling between Git for Windows and libgit2, which is the Git library that is used by Visual Studio and (parts of) TortoiseGit.
It has been decided that both implementations should treat junction points as if they are Unix mount points, however neither implementation actually does that at present.
At present, Git for Windows treats them as if they were normal directories (and so it may delete your junction and replace it with a new directory). libgit2 treats this like a symbolic link, and as a result, Visual Studio refuses to deal with it at all.
Since Microsoft will need to update Visual Studio to fix this, please file a bug at Microsoft Connect and encourage people to vote for it in the hopes that it will get fixed in VS 2015.
I'm working on a project where I'm writing a library. I have a file, lets call it... tester.cs which I use for testing the library. Now, I'm only supposed to check in the library but i accidentally also checked in tester.cs. Is there any way I can delete it from the remote server without deleting it locally? and also ultimately removing it from source control? Thank you in advance.
If you want to delete files on the TFS server and leave them locally. There's the obvious brute-force solution of copying the files to a temporary location, fixing source control, then adding them back in to your project.
And also here is a similar question for your reference: How to delete a file from TFS repository without deleting local file
It depends really on what you mean by 'delete'. TFVC has the concept of delete which flags a file as deleted in the Project Collection database (and removes it from your workspace etc.). And you have the concept op 'destroy' which means the file will be removed from the Project Collection databases, and action that is unrecoverable except by restoring a backup of TFS. But this will leave your local file in place and erase all traces of the file in source control.
However, if you added it to your project in VS (.proj file) then there will be a reference to the file in there as well for compilation etc. This will cause issues when other users perform a Get-Latest of your solution.
Also if you are using a local workspace you can use .tfignore files to prevent such files from being added into the local workspace in the first place. See this page, near the bottom there is some information about the .tfignore file and how they work.
I think it's as simple as making a local copy of a file, deleting it in TFS and moving the local copy back to the original location. Visual Studio does not allow you to do that in a C# project or Source Control Explorer.
Ok, complete Visual Studio & Windows development noob here - there's gotta be an easy answer to this.
I've just started working on porting a Linux C++ library to Windows. Existing source tree is on the Linux file system, VS is running in a Windows 7 VM, which has the Linux file system mounted.
I added the source tree to a new project - I was initially doing the edits on the linux side, but now I've done a few from the VS IDE. But those edits aren't showing up on the disk?? I've done the typical save: ctrl-s, done the "save all": ctrl-shift-s, saved from the menu, etc. If I look at the file on the disk on the linux side, the changes aren't there.
I've shut down & restarted VS, and it still sees the changes on restart. How do I get the changes back on the actual disk so I can commit to subversion, etc.?
I've confirmed that the files & file system are read/writable from the Windows VM.
I'm sure this made sense to somebody, but I'll be damned if I get it.
Visual Studio Professional 2013 on Windows 7
You shouldn't be reading/writing to the same directory under both environments, imo. Not the least reasons of which is that *nix & windows have different ideas of line endings.
It would be much better to keep a git repository on your host OS (or on a server like github) and pull/push to that repo from your windows VM. Git is smart enough to handle all the line endings, symbolic links, permissions, etc. automagically.
I have seen similar behavior using BC++ IDE.
In my case I was trying to edit files that were hard links to files in a second directory (on the same NTFS file system).
The IDE is using some mechanism to reposition the file to be edited into the _history backup directory.
I.e. the editor unlinks the original file in the original directory and relinks it in the _history subdirectory and creates a completely new directory entry for the edited file.
The hard linked file I created in the second directory is thus then linked to the backup file in the _history directory so when I edit the file in the second directory with notepad, the modifications appear in the _history backup file (or vica versa) but not the file in the originial location.
Its not like a simple text editor (notepad) where the edited file is opened-read-closed and when saved, reopen-written-closed using the same directory entry.
I presume that the IDE is using a low level Windows file system function to rename/link the original file into the _history
directory and that this mechanism does not support/recognize NTFS hard links. I suspect in your case that VS may use a similar relinking mechanism (specific to NTFS) that similarly would not work with the files in the mounted Linux file system.
That VS may be storing edits in a temporary file (may be hidden or in some other temporary directory) so the original file is not lost if the IDE crashes. When the file save is committed it attempts to link the original file to backup and then attempts to relink the temporary edit file into the original directory entry location, but because the NTFS file system linking mechanism is not compatible with the Linux file system, nothing happens.
[I do observe temporary files appear like this when editing MicroSoft Office documents. notepad++ also does this, so I suspect VS is doing the same thing.]
I am an inexperienced Mercurial user. I am using VS2010 with Mercurial. I had everything working nicely against a single repository, which contained a solution file and two projects nested within the 'parent' folder. Whenever I changed a file then the commit process would detect the change etc, etc.
Then I added a third project. I added this project in a new folder, where the new folder was a peer of the top-level folder containing the original solution file (with original 2 projects nested within). Although the third project has been added to the solution file, it is not being recognised by Mercurial as 'belonging' to the solution in terms of source control. Indeed, it is not showing as being under source control at all.
How do I add the third project to the same repository, even though it sits 'outside' the original folder which maps to the original Mercurial repository?
Thanks very much.
No, you cannot add anything that is not under the repository root. hg add will abort with X not under root message. Move your files into the repository, or move the repository so that all of your files are under the root (note that this will generate a lot of file moves, and you really shouldn't do that).
I found the best way to manage multiple folders in one repo by just creating a symlink (mklink in windows). I usually work in Visual Studio, so I typically have a code library and a website directory, but they are not in the same parent folder.
You can create a symlink on windows like so:
mklink /J "Target Path" "Source Path"
So I would have a structure like so:
project root
- Code Library
- Solution File
- Web Folder (symlink from locally-hosted website folder)
You should use a different repository for each project. This is because when you do a commit in hg, the commit is for the entire hierarchy, not just the directory (and below) that you are in. For more details have a look at the One last big conceptual difference section of http://hginit.com/00.html
I'm working on a simple file sync tool for Windows that works like Dropbox but uses SVN. (I might open source it, it's just toy right not but it works really well.)
PROBLEM: Renaming a file... I can catch the event from the Windows OS with the old name and new name. But how can I register the rename in SVN without actually doing it in the file system?
I know SVN doesn't support that, but I want thinking of some other way. For example a rename is just a copy and a delete.
For example, I could do a server side copy but then the local copy is unversioned. There's got to be a way! Any ideas!?
[And deleting all the old files and reuploading them with new file names doesn't count ;) ]
See how EasySVN deals with it. It is an open source file sync tool for Windows & Mac OS X, with autocommit, based on Subversion.