I would like to checkout a read only SVN projects (e.g. from Codeplex) to a folder on my local disk, open the solution (let's say I am getting Dotnetnuke and open it's solution, add some projects to the solution and possibly changing some files, previously making them writable.
I want to regularly update the changes coming from Codeplex and do code mergers to preserver my changes).
However I would like to copy all the files in this checkout location to another "developer" location where I would play extensively with the source code and have my local SVN repository to preserve history and allow other developers to do check ins/outs. I should be able to use TortoiseSVN from Windows explorer or Visual Studio SVN Add-on to do check ins/outs.
So check outs from Codeplex to the first location would be an intermediate location from which I would like to update
a development area in another location that will be connected to Read/Write SVN repository on my local machine.
So how to make updates/synchronizations between first and second location (direction is from first to second location).
Can I use Tortoise SVN to move changes from first location to second (after SVN update from Codeplex).
Since I am using GIT and Mercurial clients how would I propagate changes to my Development SVN location.
I would prefer solution that would work across source version software.
Tx,
Rad
You can use SVN switch to switch between repositories, although that could be tricky thing to do...
Wouldn't adding the Codeplex' repository as an external to your R/W repository do the thing? See:
http://svnbook.red-bean.com/en/1.0/ch07s03.html
Related
My Visual Studio projects are located in C:\Users\MyName\ProjectName.
To make life easier (I thought), I created a file system link in the root called TFS.
(i.e. C:\TFS points to C:\Users\MyName\Projects)
I always open my projects from the link (i.e. C:\Tfs\ProjectName\ProjectName.sln) and my TFS local paths uses the link.
This work fine most of the time but someVisual Studio and TFS think files are in C:\Users\MyName...
i.e. If I look at the properties of projects in a solution, one can be in C:\Tfs and another in C:\Users. I have verified that there are no absolute paths in any solution or project files.
When this happen and I add a new file to a project TFS becomes a real mess. TFS thinks the new file is in C:\Users and is not versions controlled but at the same time there is a file with the same name in the C:\TFS folder so I need to resolve a conflict. I can resolve the conflict but TFS starts versioning the C:\Users file. i.e. the local folder for the project is C:\TFS... but according to TFS (and pending changes) the new files live in C:\Users.
I have not found a way to change the local name of file, only a folder.
Is there a way to resolve this or should I just get rid of the link?
(It works slightly better with a TFS local workspace but the problem is still there)
<tl;dr>
Symlinks are funny things and because TFVC stores binding information outside of the source control folder, it may get very confused when your repository is stored in or includes them.
Details
Opposed to Git, Mercurial and Subversion, TFVC doesn't just keep the binding of disk to repository in a subfolder of the repository (in case of a server workspace it doesn't keep this data on disk with the repository at all). It also stores it in a number of other places, namely the TFS server and your user profile.
When you look at a subversion or git repository you'll find the .svn or .git folders which contain the information of which folders on disk map to the repository.
With TFVC this information is not only stored on disk (in case of Local workspaces), but also on the server (machine name, server path, local path) and in your user profile (under AppData\Local\Microsoft\TeamFoundation\). These configurations store the full paths and these are used to see if a file is under version control or not. The reason why Local workspaces improve things, is because they add the tf$ folder with some of the binding information.
Since a workspace mapping can map a folder in your repository only to one folder on disk, the use of symlinks confuses the TFVC client. You might consider this a bug, since Microsoft should be able to resolve the link (depending on the link type), but Visual Studio assumes you are not using links. Other reasons why this (potentially) confuses Visual Studio is that file size and other attribute changes are not always signaled in case links are used (date changed and file size may not be notified until Visual Studio is told to refresh the solution). The Read-Only bit (which TFVC uses in case of server workspaces) also has special behavior in case links are used and may cause issues of undetected checkouts.
More on the strange edge cases caused by links, can be found here.
I'm not sure why you'd want to use a link in this case, the sources are already stored in TFS, so a backup of your profile doesn't add much and only makes you system slower in case you have a roaming profile. Plus, workspaces are machine bound and should never "move between machines" magically anyway.
You can submit a suggestion on the Visual Studio User Voice, or file a bug on Connect if you want to see this behavior changed, but to solve your problem, use normal folders and map your files to a unique location.
Just keep in mind, very few applications in Windows are built to handle Symlinks, and those that are may cause strange behaviors. Windows explorer (file open dialogs and drag&drop) may provide the original file location, instead of the link location for certain actions and changes to attributes in one location may not be visible in the linked location.
As you can see here, systems will be able to see the difference between symlinks and real directories, and thus may act on that knowledge:
This is a very simple question - How can I remove Source Control from my solution and projects in order to change the SVN repository ?
I have an old project linked to an old repository, trying to move to a new one, and unable to figure out how.
The Actual place in Visual Studio that suppose to enable this is Grayed out.
Removing the .svn files form the folder doesn't apply as they are not there....
using the latest version of ankhSVN.
In your Visual2013. Go--> Tool----> Optioins--->sourcesControl
And Cuurent Sources Plug in None.
just set This. if not retuen feedback...
You seem to want to change the SVN respository that you're pointing to. There is another Question And Answer, but it seems pretty ugly.
Having installed the latest version of ankhSVN on Visual Studio 2013, it seems pretty trivial to relocate to a different SVN respository.
Right click on the Solution -> Subversion -> Switch Solution
On the menu, you should have an entry pointing to the current location of the solution. If the repository is the same, but under a different URL e.g. changing hostname, directory, etc, then simply change the relevant pieces in the URL and hit enter.
It will prompt you that the root you've specified is different from the one that you're currently using and you can simply relocate it from one to the other - i.e. choose to relocate. It will then prompt you a second time to switch, but this should be a free change.
If the new repository is different to the old one i.e. it's somewhere completely different in a different repository with a different repository ID then you're going to have to do some form of manual changing by following the instructions on the other answer.
If you want to remove the svn metadata for the project, it's in a single directory called .svn at the root of the solution that was checked out from subversion, as well as removing the information in the .sln file that mentions AnkhSVN (it's probably the only entries mentioned in a specific GlobalSection in the file mentioning source control). That purges all the svn data from the solution.
I want to view all changes locally that have been checked into TFS.
Specifically, I want to take my laptop from work to home, and view all changeset other members checked in, but I cannot connect to my work's VPN tfs server.
Any idea would be very much appreciated.
You can use Git-tf to get a local Git repository (using it for read only). You can then look at the history without TFS connectivity, with Git command line, or visually with a GUI like Git extensions.
First, clone your TFS repo with git-tf.
If you want the entire history, use --deep, but it may take a very very long time. You may want to use --shallow instead to do a quick clone, but you won't have the entire history, just the history from this day on (like it was the first commit).
git tf clone --deep http://myserver:8080/tfs/mycollection $/TeamProjectA/Main
Then, whenever you want to update your repo, follow this step
git tf fetch --deep
It may take some time though (since git-tf is getting every single new commit, and TFS is not optimized for this scenario). You can make a script which run this command every hour.
Using Git will have another advantage : looking at many diff in TFS take some time (since there is a server connection for every file you want to compare with the previous version, and some clicks needed), but in Git extensions it's really quick, in the same window you can view the history of commits, the current commit files, and the current file diff, instantly (no server connection).
You can run the changeset report and save its output. Other than that you are going to need to be able to connect to TFS. It is possible if you have problems with vpn that you might either need to connect via ip address ot check your credential manager to make sure you are setup.
If you were using TFS 2013 and a Git repository you would be able to do this. In the non-git style TFS Source Control (TFVC, the only option before TFS 2013), everything is centralized on the TFS server and without connectivity you are extremely limited.
TortoiseHg is sending me mad! No pun intended.
I am a solo .NET developer just trying to achieve good source control e.g. diff and revert.
I wish to have a central repo on a network share e.g. "\\server\repos\DO I NEED A FOLDER HERE"
and a local copy e.g. "... My Documents\Visual Studio 2010\Websites\My Website"
but the quick start guide http://tortoisehg.bitbucket.io/manual/2.4/quick.html is not relevant in my case - I don't think I want to clone the repository?
Please could someone outline the steps and their order to achieve:
Local copy
Central repo on network share (which is backed up regularly)
E.g.
Create folder for repository "\\server\repos\My Website"
Link ".. My Documents\Visual Studio
2010\Websites\My Website" to repo
Add files / commit files - I'm unsure of the terminology here
or point me in the direction of some idiot-proof documentation.
I chose TortoiseHg because I thought it was modern and simple.
Should I have gone with Source Gear Vault instead?
Any help appreciated!
I'm far from an expert but I believe that you do want to clone the repository to start with. You will treat your network share just as any other "server"(bitbucket, etc). So you clone from the network share to your local machine. Then any commits you do will be on your local machine. When ready to send to the network share then just do a push. The process is exactly the same but instead of some web address you can push to your network share.
What I would do is create the repository on your network share. Then I would clone it locally. It really is simple. Once you have mercurial installed, you can just hg init any directory and you have a working repository. Then it's just a matter of setting up the shortcuts to point to the right places so you can do something like hg push netshare instead of hg push \\server\repos etc.
Also, adding files is not the same as committing. When you add files you are telling mercurial, "Hey, I want to keep track of changes to this/these files". When you commit, you are telling mercurial, "I've modified my files and I want you to record the changes since the last time I committed".
I'll try to make this as straight forward as possible.
Currently our team has a VSS database where our projects are stored.
Developers grab the code and place on their localhost machine and develop locally.
Designated developer grabs latest version and pushes to development server.
The problem is, when a file is removed from the project (by deleting it in VS2008) then the next time another developer (not the one who deleted it) checks in, it prompts them to check in those deleted files because they still have a copy on their local machine.
Is there a way around this? To have VSS instruct the client machine to remove these files and not prompt them to check back in? What is the preferred approach for this?
Edit Note(s):
I agree SVN is better than VSS
I agree Web Application project is better than Web Site project
Problem: This same thing happens with files which are removed from class libraries.
You number one way around this is to stop using web site projects. Web Site Projects cause visual studio to automatically add anything it finds in the project path to the project.
Instead, move to Web Application Projects which don't have this behavior problem.
Web Site projects are good for single person developments.
UPDATE:
VB shops from the days gone past had similiar issues in that whatever they had installed affected the build process. You might take a page from their playbook and have a "clean" build machine. Prior to doing a deployment you would delete all of the project folders, then do a get latest. This way you would be sure that the only thing deployed is what you have in source control.
Incidentally, this is also how the TFS Build server works. It deletes the workspace, then creates a new one and downloads the necessary project files.
Further, you might consider using something like Cruise Control to handle builds.
Maybe the dev should take care to only check in or add things that they have been working on. Its kind of sloppy if they are adding things that they were not even using.
Your best solution would be to switch to a better version control system, like SVN.
At my job we recently acquired a project from an outsourcing company who did use VSS as their version control. We were able to import all of the change history into SVN from VSS, and get up and running pretty quickly with SVN at that point.
And with SVN, you can set up ignores for files and folders, so the files in your web projects dont get put into SVN and the ignore attributes are checked out onto each developer's machine
I believe we used VSSMigrate to do the migration to SVN http://www.poweradmin.com/sourcecode/vssmigrate.aspx
VSS is an awful versioning system and you should switch to SVN but that's got nothing to do with the crux of the problem. The project file contains references to what files are actually part of the project. If the visual studio project isn't checked in along with the changes to it, theres no way for any other developer to be fully updated hence queries to delete files when they grab the latest from VSS. From there you've got multiple choices...
Make the vbproj part of the repository. Any project level changes will be part of the commit and other developers can be notified. Problem here is it's also going to be on the dev server. Ideally you could use near the same process to deploy to dev as you would to deploy as release. This leads into the other way...
SVN gives you hooks for almost all major events, where hooks are literally just a properly named batch file / exe. For your purposes, you could use a post-commit hook to push the appropriate files, say via ftp, to the server on every commit. File problems solved, and more importantly closer towards the concept of continuous integration.
Something you may want to consider doing:
Get Latest (Recursive)
Check In ...
Its a manual process, but it may give you the desired result, plus if VS talks about deleted files, you know they should be deleted from the local machine in step 1.