A while back we renamed the main folder where our project source code is, and for some reason, TFS represents this as a discontinuity in the history:
This is kind of annoying, because whenever I need to look at something from before the rename, I have to keep expanding the child nodes until I can continue to search. I've also just discovered that when enumerating through the history using the API (via VersionControlServer.QueryHistory), it stops at the rename (changeset 1172).
This is getting very annoying. Is there any way to fix this break in the history? Failing that, is there a way to get QueryHistory to return the full history, including before the rename?
For the api question:
I vaguely remember how history was rewritten in Visual Studio 2010. I also peaked at MS.TF.VC.Controls.dll in ilspy, I hope Chad will forgive me ;) What works for sure for files renames (I would hope for parent renames as well) is to use QueryMergesExtended and specify to include sourceRenames. A rename in TFS 2010 and later is branch and delete, so you can find source of every rename, by following where it was branched/merged from. It will definitely require some coding on your part.
For the UI question (I know I'm backwards here) what exactly are you searching? Comment? Filename? Specific content change?
It appears that there's no way to get the UI to do what I want. But on the API side I realized that the break in the history was actually caused by the way I was searching:
Dim changeSets = vcs.QueryHistory("$/ProjectWithCurrentName", RecursionType.Full)
This wasn't finding the changesets before the rename because I'm searching by name and the name is different. So now I just run this twice, once with the new name and once with the old, and merge the results.
Related
I've got a file managed by Visual Sourcesafe 2005 which I have edited. I'd like to check in the file exactly as-is on my box, but VSS always merges it with the file in the repository, breaking my code.
I don't know what I expected to happen...
Is there any way to check the file in without merge shy of deleting the existing file from the repo and adding my copy back in?
I've looked for command line options to no avail.
You could just do "Undo check out" for all files, keeping their local versions on your machine; then again check out this files without getting latest versions from Visual SourceSafe; then check in all of them. In this case history is preserved. You just overwrite latest versions of files without any merge. Seems for me it's what you wanted.
I had the same problem and sorted it out in that way.
I'm putting this answer here, but still really hoping that a better one comes up.
I figured that I can go into the VSS GUI and rename the file to ".old", then add my local file into the repo. It's extremely hacky, but allows me to keep the file history.
Such issue might happen when the file was checked out by multple people and there was a newer version checked in by others after your checkout. (See Four scenarios that merge may be performed #2 of the article for more details.)
I don't see a option in SourceSafe CheckIn command to control that either. If you don't want merge happen, you may exclusively check out the file before editing.
I want to use a versioning system to back up and track my changes but I'm too lazy to check out/check in, merge, commit, etc. I don't want to branch, fork or anything else. I just want to be able to see what files have changes and what my Main() looked like last week.
So I'm looking for an application that will simply take my Visual Studio projects folder and back it up in such a way that all prior versions of the files are preserved so I can not only have a backup, but I can easily see how the file looked at some point in the past without me having to explicitly put it in a repository, update/commit/merge/etc.
Basically what I'm looking for is dropbox's functionality but on my local machine and without the 30 day limitation of prior versions.
Does such an application exist?
As AlexC stated, I highly doubt that the little bit of work you save by not using a version control system explicitly is worth the drawbacks, but anyway:
Simplest idea: Just write a wrapper script that checks out the HEAD of your repository, starts Visual Studio and commits everything to version control after you close it.
Alternatively, just trigger commits every hour. With most VCSes, non-modified files won't show up in the listing of modified files.
I have a Visual Studio 2010 Database Project. It works great for most stuff.
However one thing is very annoying. Say I have a table called dbo.MyCoolTable. If I go the the database and rename it to dbo.MyKindaCoolTable it works fine in the database.
However, when I do a schema compare and write the changes back to my Database project it leaves the old file in the project. So I end up with two files (dbo.MyCoolTable.Table.sql and dbo.MyKindaCoolTable.Table.sql).
Once or twice this is not a problem, but over time this really adds up. And it is tedious to go through the project and manually delete each of these "left over" files.
Is there a way to just delete the "left over files" when I write to my Database Project from a Schema Compare?
Not that I know of in the current world, but some of the the Denali changes help with syncing code. I have not seen how far they take this paradigm, or had time to play with it, however. I know that does not help in the current world.
I recently found out this was happening to me too, so I wanted to find all the old files which have been commented out and delete them.
The scripts end with a ";" and the ones we want to get rid of are commented out, so doing a find and replace for all instances of ";*/" in the project (without the quotation marks) does a pretty good job of finding the scripts we want to get rid of, then it's just a matter of manually deleting the offending files from the project.
I wish there were a more elegant solution...
I hope this qualifies as programming related since it involves how to structure a project.
Because I've always used the web site model with VS.net I never had solution and project files and putting everything into source control worked great. I knew that everything I had in my web site directory was all I needed for the web site.
Now I'm using asp.net MVC and it only has a project model so now I have these solution and project files. If I work on it alone it's fine but once other people start to add/delete files from the project our solution file gets messed up and people end up having to grab the latest solution file, see what got changed and then add back/remove their files and check in the solution file again. It's become sort of a problem because sometimes people don't realize the solution file was changed, they make other changes and then when they check in everything other people do an update on their files they find that their files are gone from the project (although still physically on disk).
Is this normal? Is there a way to structure a project so that we don't need to check in solution and project files?
Your developers are not using TFS correctly. You should have multiple check-outs turned on, and everyone needs to be careful to merge their changes correctly when checking in. TFS will prompt you to do this, and accepting the defaults is nearly always the right thing to do.
It's not uncommon to have one or two developers who never get it, and you might have to help them now and then. But every programmer who works on a team needs to learn how to use source control tools correctly. If they can't manage that, they shouldn't be writing software.
[edit] It occurs to me that you might run into these problems if you check in the *.sln file directly, rather than choosing to "Add Solution to Source Control".
I don't think it's normal - what are you using for source control? It sounds like developers aren't respecting changes that others a making - checking in without merging first.
I know that early on in a project, when lots of files are being added & deleted, it can be a problem to keep up - you need to check out the project file, add your files, then check in the new file & project so other developers can also update it. You'll probably have multiple project files in a solution - perhaps one interim solution would be to have one "holding" project for each developer, then clean them up periodically - though these types of temporary fixes do have a tendency to become permanent.
I don't know of a way to set up a project file that's not in source control, though I suppose you could create a script that would generate them.
Having been through this, the key is respect & good communication between the developers.
This tends to happen with TFS multiple check outs. It can be hard to grasp coming from VSS to TFS as VSS allowed one person to check a file out at one time. Auto-merge should work most of the time for you but a couple of rules should ease the pain:
Check in early and often (if you add remove or rename a file check it in straight away even if it is a blank holder)
Before you check in do a get latest, this will ask you to resolve conflicts locally
Try to get continuous integration set up so that developers always know the state of the buidl and whether it is OK to check in\out.
We had a bit fo pain at the start of our current project but it soon settled down when we followed the rules above.
Personally, I think making changes to project and solution files requires discipline and clear (well understood) rules throughout your development team. These files (.sln, .*proj) are the bottlenecks of your project, and any errors or inconsistencies can cost you in team downtime. Changes need to be well thought out, planned and then executed.
They must be secured by source control (which you're already using, excellent) and your team members should work on the basis of only making the changes they need, and not leaving project or solution files checked out for an extended period.
If you are allowing multiple (shared) checkouts, this could become problematic in terms of overwriting another user's changes. Depending on your source control mechanism, people may be required to manually merge changes. Personally, I'd ask people to negotiate their project/solution changes with each other over merging (this can't always be achieved).
A third option if you are using TFS is the shelve feature. If someone needs to make changes locally, they can shelve the changes and merge later.
Lastly, another strategy is to try to architect your solution to be as modularized as possible - so people are distributed, working on separate projects and do not (ideally) have to overlap on too many common areas.
I'm not sure if you are using TFS, as people have mentioned, but if you are (or if you are using source control with similar capabilities) you can set it such that sln and csproj files are exclusive lockouts and are not able to be merged.
We have done this with quite large teams and while it causes some initial issues as people get used to it in the long run it has resolved many issues that were previously causing problems. Essentially you trade longer term merge issues/complexity for short term compile/checkin issues which we have found to be a good trade off.
Once you have set it to forced exclusive checkout and no merge you then get your dev teams used to the fact they should keep locks on the sln and proj files for as shorter time as possible.
Always check them in.
Always check out latest (merge if possible), make sure your change is there, before checking in a new version.
If your source control doesn't require a special action to check in from an old version, GET A DIFFERENT SOURCE CONTROL.
I'm using Visual Studio 6.0 and Visual Basic 6.0.
I have them integrated but when I check out a Project and then try to edit a module in that project it's locked and I have to manually right-click on it and do a Check Out to unlock it.
I thought there was a way to have VSS automatically check out the file for editing.
Any suggestions?
I agree with kris here. Now I know that a bunch of folks saying your "software stinks" doesn't really answer your question. But there is a world of difference between a check out style source control and a file locking system like Source safe. The general consensus is that Check out systems are far superior.
With check out, what you do is you check out the project from your repository. All the files are editable. You work on your project as normally. Then before you checkin you do another update. If anybody else in your team did a update the software will automatically merge in the changes into your code. You will have a chance to review the merges and resolve any conflicts. After the update you can then check in your changes which everyone else can retrieve.
The big scary part is the merging part. Back when CVS and subversion where just command line tools it was a little scary as it was a pain to retrieve what happened with the merging. But with today's tools like Tortoise is all visual. In the last couple of years I can't think of any instance where a automatic merge failed. Any conflicts (basically two people edit the same line of code) are display right here for you to resolve.
Subversion
Tortoise SVN
There is an option in SourceSafe under the "Local Files" tab labeled "Use read-only flag for files that are not checked out". By default this option is selected, but if you unselect it, you will be able to edit any file in the project without checking it out.
Once you uncheck the option, you can get the latest version of a project to remove the read-only flag from all the files.
When you check out a file, you will be warned that there is a writable copy of the file in your working folder, at which time you can replace it with the version in the SourceSafe database.
I never figured out a way to do this. It was always a huge pain. Sorry for posting a negative answer, but I figured that you might want to know that you aren't alone in hating this, but that there wasn't an immediate and obvious answer. I'll be following this question along with you in case someone out there does know of a solution...
I don't think it is possible to do this (at least it wasn't when we used VSS eight years ago), but while you are experiencing the pain of a check out styled source control, run - don't walk, to some real, non-locking style source control solution. SVN, CVS, Git, Mecruial, anything that doesn't lock files, and doesn't leave your source in a proprietary file sytem. We switched to CVS eight years ago because we lost all of our source history (the code was checkout out so it was retrievable), due to a VSS glitch. Best thing we ever did, made collaboration ten times easier. Now CVS isn't the best solution (it was the most reasonable solution for windows back then), but anything is better than VSS.
Best solution I found was to check out all the files. Took a bit of poking around to figure out how to do that. Here's how:
How to check out all VB6 Project files from VSS?
when I check out a Project and then
try to edit a module in that project
it's locked and I have to manually
right-click on it and do a Check Out
to unlock it
Like it or not, it works that way by design i.e. you can check out all the files but you have to explicitly choose to do so, rather than being the default option. I guess that's because checking out all modules (class modules, forms, usercontrols, etc) locks out all other users from the entire project, which is normally undesirable in a team collaboration environment.