By accident somebody commited cache files to SVN (svnignore was wrong)
I updated the SVN ignore and want now to remove all the currently ignored files from the SVN (local copies should be kept).
How do to that?
You will have to remove the ignored items in the repository first and ask the users to run svn update as they always do. The items will be removed in the user's working copies and this should be completely OK just because every user at the moment should be seeing constant conflict errors, especially when he rebuilds the project.
Once you remove the cache files, they will be ignored in the working copies and no one will commit them by mistake anymore.
Related
I have a project under source control using TFS and Azure DevOps.
It all works normally except for one thing: When I check in a file, I get this error message:
TF10122: The path '$/KnowledgeBuilder/V2/$tf/1/1f8c47a1-8066-42d7-b56c-c9960b0ee7ea.gz' contains a '$' at the beginning of a path component. Remove the '$' and try again.
The check-in does in fact succeed, but I get three of the above error messages each time. I can simply ignore this, but it is starting to get annoying.
It appears the folder in question is a TFS created and controlled folder. I tried deleting the folder, but that remove the Project from Source Control, so I restored them.
Is there a way to resolve this?
This occurs in VS22 on a Blazor Server Project. I have tried opening the Project in VS19, making a change, and then checking it in, and it works fine. So, it must be something specific to VS22.
Someone, sometime, at some point, added that $tf folder to version control. It should not be there, ever, under any circumstances -- that's the folder that TFVC uses to track local workspaces. That's why removing it messes up your workspace.
Make sure any pending changes are committed or shelved first.
Remove that folder from source control. Make sure the change is checked in. You might need to use a server workspace to do this so that the $tf folder isn't relevant.
Use tf get to force a re-sync of your local workspace. tf get /all /overwrite should do the trick. If it doesn't, then just delete and recreate the workspace.
Add $tf to your .tfignore file (although if memory serves, that shouldn't be strictly necessary -- I haven't worked with TFVC in a few years)
I am using Windows and Git and I had modified a file. No matter how many times I did a git add and commit, the file kept showing up as modified and i could not for example do a git pull --rebase. I assume I did something wrong and screwed up the local Git repo so I decided to clone the repo from github, into a completely new directory. To my surprise, even in this new directory tree when I do a git status the same file shows up as modified -- it is as if it is somehow modified in the github (remote) repo which does not make sense to me. Moreover, the version of the file in cloned local repo does not have the latest version of the code that i can see when i look at the code on github. How can i fix this? I am concerned that someone else cloning the code will end up with the same problem. (Apparently only I am seeing this problem -- I did not somehow manage to corrupt the github repo which leads me to believe this is a git/windows issue.) As far as what I think I did wrong is when I modified a file and did a git add, i misspelled the directory path by using a lower case letter instead of an uppercase and then adding one file resulted in the other, properly spelled path showing up as modified and vice versa. I don't know if a symlink on windows got created -- the file contents are identical. But one would think cloning (via Eclipse) into a completely new directory tree would make this a non-issue.
I looked through replies but it seems like the basic problem is Window's case insensitivity and this caused some (to me) weird behavior. In particular, I simply could not delete one of the folders -- they were "entangled." So the simple solution was to delete the folder and its contents from unix which is case sensitive. Then I checked out a fresh repo and problems appear to be completely resolved.
You mentioned in a comment that you discovered one commit containing two problematic files: one named Login/Login.tsx and one named login/Login.tsx. This comment is on a related question; see my answer there for a discussion of Git's method of naming files in its index, vs what your OS requires in your working tree.
Your solution—use a Unix or Linux machine, where you get a case-sensitive file system, to repair the situation—is probably the easiest and best way to deal with this. If you can establish a case-sensitive file system on your own machine, that also allows easy dealing with this (see my answer to another related question for a macOS-specific way to make a case-sensitive file system).
Given that what you wanted was simply to delete one of the spellings, though, git rm should allow you do that. In particular git rm --cached login/Login.tsx would drop login/Login.tsx from Git's index, without affecting Login/Login.tsx. This could leave your working tree with an existing login folder, though.
It's important—at all times, really, but especially when working within a situation like this—to realize that Git itself doesn't actually need or use your working tree to make new commits. Each commit contains a full snapshot of every file that Git knows about. These files exist as "copies" in Git's index.1 Hence there are actually three copies of each file:
A frozen version of each file appears in the current commit (whatever that commit's hash ID is).
A "copy" (see footnote 1) of that version appears in Git's index. You can replace this copy with different content, and the read-only copy in the commit doesn't change. You can remove this copy entirely, and the read-only copy still doesn't change. Nothing in any existing commit can or will ever change. The index copy exists precisely so that you can replace it, or remove it, or whatever. In effect, the index—or staging area, if you prefer this term—acts as your proposed next commit. It's merely filled in from a commit.
Finally, there's a regular, ordinary, everyday file. This copy goes into your working tree or work-tree. To put this copy in place, Git must use your OS's file-manipulation facilities. That may require creating folders and files within the folders. If those are case-insensitive, and Git goes to create a Login folder when a login folder exists, or vice versa, the OS will say: nope, sorry, already exists. Git will do its best to accommodate the OS by using the "wrong" case anyway, and will create a file within that wrong-case folder—or perhaps destroy some other work-tree file that has the same name except for case, or whatever.
This last bit, where your work-tree files end up with the wrong names and/or in the wrong folders and/or end up overwriting similar files whose name differs in case somewhere, is a problem for you. It's not a problem for Git, though. Git just keeps using the index copies of each file. The next git commit you run uses whatever is in Git's index. The fact that your work-tree doesn't match is not a problem for Git. It's just a problem for you, because the normal everyday git add command means make the Git index entry for this file match the copy that's in my work-tree, and if that's the wrong copy, well, that's a problem.
In any case, once you have a correct commit in Git as your current commit, and extracted into Git's index, you can do whatever you like to your work-tree, including remove large swaths of it, or rename folders, or whatever. Get it set up however you like, then use git checkout or git restore to re-extract all or part of the current commit to your work-tree. Now that you've eliminated the name-case-issues in Git's commit and index, and cleaned up or removed any problematic files and/or folders in your work-tree, Git can create correct-case folders and/or files as needed. It's the process of getting the correct commit into Git that's painful, except on a case-sensitive file system.
1"Copies" is in quotes here because the files in Git's index—which Git also calls the staging area—are in a special Git-only format that de-duplicates content. When the copies that are in Git's index match the copies that are in some existing commit, Git is really just re-using the existing commit's files. Files with all-new content actually require a new internal blob object, which Git creates as needed; after that, the content will be de-duplicated as usual.
I have two branches say dev and rel. If I am changing file 'A' under dev and without commiting I will mergr to rel, I am getting change status as "[merge]". And If change the file, commit it in dev and then merge to rel status will be "[merge,edit]".
Is there is any option in VS 2013 where it should not allow to merge the file for developers if it is in checked-out state.
Scenario:
One file already committed to the server with change and second file is in checked out mode and not checked-in to the server.
So first file merged separately which got merged and then after changing the second file, added first and second file in single change set with checked out mode of second file. So no conflicts while merging because second file code was in checked out mode..
How to go ahead where - Developer cannot merge if file is in edit mode.. it should allow only when changes are checked in to server.
No this isn't possible. The ability to edit files during merge is required in order to be able to perform conflict resolution.
In TFS, merge specifically means that its this revision contains the merge from a another branch. however,merge only represent the merge operation. So it shows [merge] status for the unchanged file and shows [merge,edit] status for the files that actually changed and shows [merge branch] for the new add item.
It's not possible to restrict users to do the merge files when the files be checked out. This is used to resolve the conflicts.
We do not have this kind of build-in feature for local workspace. If you are using server workspace, you could try to sue Check-out lock for target branch, a check-out lock prevents users who are using server workspaces from checking out and making changes to the locked item in their workspaces. You cannot apply a check-out lock to an item for which any pending changes exist, in any workspace other than your own. More details take a look at this link.
We use VisualStudio with SVN and VisualSVN.
I restructured the solution by moving (cut and paste/drag and drop) and renaming a lot of files.
Never heard a complaint from VisualSVN, now it is time to commit it refuses to do so:
Commit failed (details follow):
Error: Cannot commit 'C:\Sources\xxx' 'xx\Model\Model.cs' because it was moved to
'xxx\NewModel.cs' which is not part of the commit; both sides of the move must be committed together
That is correct neither file exists any longer at the given positions, and frankly I don't care.
I need SVN to store the solution as it is now. It is OK that I will not be able to trace change history for moved and/or copied files.
Is there a way to force the commit?
It seems that you get the error because you commit only the part of the move action. Moves in Subversion consist of svn copy (to the new item location) followed by svn delete (of the original item), so both sides of the move must be committed in one revision together.
I suggest following these steps:
Visual Studio | VisualSVN | Commit....
Make sure that both sides of the move you've performed are listed in "Changes made" list view and try to commit. Do you still get the same error?
If the first step fails, go to Visual Studio | VisualSVN | Windows | Pending Changes. Right-click the root node of your solution / working copy and choose Commit.... Still getting the error?
Go to Visual Studio | VisualSVN | Set Working Copy Root... and make sure that the working copy root points to the root of your solution's WC. Attempt to commit after this step.
I ran into this exact problem over the past week while refactoring some code and renaming numerous files. I was able to correct the problem as follows:
I committed my project folders one at a time (at the folder level) to isolate the problem. In my case, all but two folders committed without errors.
In the problematic folders, I committed the files individually. I now had a green dot next to every file, but the two folders were still yellow.
I tried to commit the folder again. It gave me the same error, but now it just showed the files it was having an issue with in the dialog box.
The files that were giving me a problem were files that had been deleted and not on my drive. I right clicked on each file and reverted it. This put the file back on my drive, even though it wasn't part of my project in VS.
Lastly, I added the file back to the project in VS and then immediately deleted it and committed the project. Everything appears to be fixed now.
TL;DR -- If SVN thinks a file is part of your project, but the file is missing from you HDD, it will give you this error. Simply revert the file to get it back on your drive. To clean it up, add the file back into your project and then delete it within VS to get everything in sync.
Please click refresh button first, after refresh in commit package Visual Studio will be included delete and rename rules, needed for SVN
I have been using XCode with subversion for some time now, no problem was caused when I was using it as a single developer (I was using 2 commands only, commit and add).
But now I have to share the code with another developer (who has never used any kind of version control) and integrating/merging the code has become a nightmare. No problem occur when we are integrating/merging .h/.m files but as soon as it comes to ".nib", "xcodeproj" and ".xcdatamodeld" files, we really don't know what to do.
Whenever we try to merge "xcodeproj", project was getting corrupt and merging ".xcdatamodeld" was kind of impossible for us.
So I was wondering if someone can share his/her experience on how to effectively use subversion/git/mercurial with XCode 4.0 in multiuser environment? or share a link, which can explain how to use subversion effectively in multiuser environment.
Thanks.
Are you doing this using Subversion? For 90% to 99% of the files in your repository, the standard Subversion workflow of checkout, edit, commit works well. However, for some types of files such as JPEGS and GIFS simply don't merge well. In this case, you'll have to do it the way we use to in the old SCCS and RCS days: Before you can edit and commit a file, you must lock it.
Locking a file prevents others from editing the same file and committing changes while you're doing your work on the file. It's crude, but it works. In Subversion, you can always lock any file you're editing, but if the file has the property svn:needs-lock on it, it will be checked out as read-only. You have to lock the file before editing it to make it writable, and you're not allowed to commit the file unless it is locked.
So, for those files, set the svn:needs-lock property on it.
You can automatically set this property on all newly added files (depending upon suffix) via setting the auto-properties in your Subversion client configuration.
And, if you really, really want to make sure that all .nibs and xcodeproj and all of the other flies of these types have svn:needs-lock set on them, you can use my pre-commit hook which will prevent these files from being committed unless this property is set.
There is no failsafe way to merge these kinds of files that I am aware of. So you will have to
try to ensure that only one person is changing these files at a time. That won't work always, so just log what you changed in the file with the commit message. Then if there is a conflict, you can manually resolve it by taking the version that changed more of the file and redo manually what the other person did.
That's normally not a big deal, like adding a new source file to an .xcodeproject, or changing the alignment of an element in a .nib. It's becoming a problem if your project is huge or your nib is containing the whole interface. For it to work well (which in practice it does), you need to split up your projects into sub-projects if they grow too huge.
I had the same problem with 2 other developers Xcode with git. Unfortunately, Xcode project files are an XML file, tracks file included in the project as well as setting. I'm not certain, but I think .nib files are also XML files as well. Someone can correct me on that.
Git did a great job at merging the Xcode project file, and never really had any problems with our *.nib files either. The only time we did have a problem is when we both added/removed files with the same names, or someone did a lot of heavy removing and adding of a lot of files.
The only way we solved this was to have each other push ann pull as soon as we added/removed files. So that way the person had the latest files, and didn't add them in their own repository then pull the latest commit which had the same file in it. Or they work adding changes to a file that was removed or renamed.
That is the best solution we found, as soon as we added or removed a file have everyone else in the team pull. Not a great solution btw. However, you should be committing often anyways.