I have never really used the Git GUI Here from the context menu in my File Explorer. I always use TortoiseGit.
However, today I decided for curiosity to use the aforementioned utility. I noticed on the File menu it had Verify Database. It did come up with some results:
Comments about dangling commits and blobs.
My primary question is how do I do this database verification with TortoiseGit? And related to this, what is the importance of the results returned to me?
Thank you.
Related
I'm pretty new to programming, and I'm having an incredibly difficult time making GitHub and Visual Studio Community 2015 play nice with each other. Usually the first commit goes well, and I can see it on GitHub.com just fine. But it never lets me make any more commits. I make changes to the file, save it, but the commit button in VS stays grayed out. I've been all over the Team Explorer to figure out what I'm doing wrong, and I can't figure it out. It says I have no unpublished changes or anything, even though I'm changing tons of things in the file.
Is there any reason it would stop working after the first commit?
Close VS
Open the particular .sln file from the repo
This worked for me.
You would need to add your username and email in you global configuration. Then you will be able to see the commit button enabled.
I had to add username and mail in VS to activate the commit button. The visual studio message telling me to add the data only appeared after a restart of VS. Maybe this will help someone else.
Try to use git push on git shell, the console will tell you if there are any errors, and give you searchable errors.
I think I figured it out, and as predicted, I'm an idiot. I was accidentally saving the files OUTSIDE the local repo folder. If anyone else has this problem, make sure you are saving things in the right places. Also, cloning the remote repo instead of trying to create two in each place helped a lot.
If you have a local database file, then you will not be able to copy/move the database file, and so any change in the solution cannot be committed. You have either to close the database service, close the connection inside the application or to close the solution and do the commit.
In source control systems and tools like tortoises for svn or sourcetree for git, when I am committing a merge, I can usually just left a default comment generated by the tool that is basically a summary of what changes were merged. In visual studio using TFS, there is a comment textbox right above the changes list, but I have to type it all manually. It's not super important but it is a time saver sometimes. Maybe i'm just not looking at the right place.
If you're using TFS with Git, then this becomes less of an issue. When you merge all the individual commits come along for the ride, so it's not necessary to re-describe them in the merge commit.
Try extension Auto Merge
If you need set original comment setup Settings "comment_format" like {{OriginalComment}}
I have used TFS a lot, and unfortunately I don't think that option exists. I usually copy my original checkin text and then paste it if I am doing multiple merges. I realize this is a low tech way to do it and the original comment isn't generated for me. If you want to be able to do this bad enough, you can probably write a Visual Studio plug in that would do it for you, or you could code up just about anything you want to add with the Team Foundation Server SDK.
Recently switched jobs and with it switched source control from TFS to SVN, which is new to me.
In TFS there was an option to disable automatic checkout of files when you started typing in them. It's enabled by default and a lot of users like this behaviour, but I prefer to know for certain what's being changed before committing. A personal thing.
VisualSVN auto-checkouts by default. Is there an similar option to turn it off? I can't seem to find out in the settings.
"Automatic checkout" term in SVN and in TFS worlds has different meanings, as far as I see.
In Subversion, checkout relates to svn checkout operation which gets a working copy from a repository. In TFS it looks like the term somehow relates to automatic locking mechanism.
If you want a file to be locked automatically when you start modifying it in Visual Studio (with VisualSVN extension installed), see the KB article "Lock-Modify-Unlock Model with VisualSVN". I also suggest reading the SVNBook chapter "Locking".
Generally speaking, you can set svn:needs-lock property on files. The property instructs client which files must be locked before editing. After applying svn:need-lock to a file the file gets read-only attribute. Before editing the file must be explicitly locked by the user. After committing the lock is released by default.
Short answer: I don;t think you can do this without becoming very unpopular.
I think you should read up on the SVN redbook's description of how SVN works, especially the versioning models
In your environment, everyone wants to be able to modify any file locally and then send their changes to the server, merging changes with colleague's changes if necessary. This approach works well if 2 people are not changing the same files all the time, which is typical of most dev shops.
The old TFS/VSS model of checkout a file to work on it is pretty obsolete today - the more 'optimistic' approach where you assume you have exclusive access is much more productive. (as usual its easier to ask forgiveness if it goes wrong than ask permission every time)
Your main problem is that you cannot mix these models - if your colleagues are using the merge model, then you have to as well. You cannot lock a file and expect them to still be able to change any file anytime.
Now, there are tricks you can use to prevent yourself from modifying files you never meant to - I'm not sure of VisualSVN but TortoiseSVN (awesome tool) can run client hooks - ie you can write a program to run on every checkout, and that program can be as simple as setting every file's read-only flag. Whether this is god enough for you is another matter.
Personally, I would get used to the idea of change whatever you like whenever. If you accidentally edit a file, you can see the change indicator (AnkhSVN turns the file icon orange for changed files), and its easy to 'svn revert' changes you didn't want to make. Also SVN lets you see diffs really easily, especially on commit - double click the files in the commit dialog. The productivity gains from being able to work without the tools getting in your way (as I found with TFS continually pinging at me as I tried to edit a file) are huge. The SVN tools are really good to let you "ask forgiveness" so you don't need to run in the crappy old TFS way now you've upgraded to something better.
The other advantage is that this applies to files that are not in a Visual Studio project, if you've ever had a project file that was edited outside VS (eg a generated WCF client stub) then you will appreciate how SVN works - never again will you do a full commit and find that TFS has conveniently decided that your changed file wasn't changed and so didn't need to be committed!
If one chooses to "prevent other users from checking out and checking in" from Team Foundation Server:
Can anyone reach the code?
Is there any way to work from another user's computer?
How about shelving?
I would interpret that sort of lock as meaning that someone is going to do something so destructive that it is in your interests to not have an edited copy when that happens. If you think it is a mistake, talk to the person who locked the file.
An option, if you really want to do this, is to remove the readonly attribute on the file yourself (in Windows Explorer or through a shell) and edit the file. That is a good way to cause yourself trouble, though, if the file is going to be changed substantially by the person that locked it. Also, you will need to later mark it as checked out in TFS to actually check it in.
I do not think you will be able to shelve the file (unless you follow the option below) since you will not be able to check it out for edit.
One last option is that you could branch the file, work on the branch, and then merge it back in later. Once again, though, that may be difficult if the edits by the person locking the file are going to be extensive.
I'm not sure I understood all of your questions, but I'll give it a chance:
If by reach you mean, get latest version and read, yes they could. But they wouldn't be able to change the code while it's locked unless they circumvent Visual Studio and change the read-only attribute of the with the command-prompt, Windows Explorer etc.
Visual Studio and TFS 2010 introduces the concept of permissions on workspaces. A workspace now can be private (the old behavior), public limited or public. Using a public workspace, on could edit the files in the workspace of another person. See tf workspace /permission for more information.
You can shelve anything that is in your workspace regardless of locks on anybody's workspaces.
Here is a link to the permission values for TFS
http://msdn.microsoft.com/en-us/library/ms252587.aspx
This should answer your questions
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.