I ended up having a few Tortoise and/or Subversion malfunctions, and somehow ended up with several versions of the same project:
...\Projects\
MyProject
MyProject(1)
MyProject(2)
MyProject(2) is the one that is the "true" one, and is thus the one I want to keep.
I cut and pasted both MyProject and MyProject(1) to a "holding tank" for eventual deletion, so that I now have:
...\Projects\
MyProject(2)
Now I want to change the name MyProject(2) to MyProject, but I'm afraid to - Tortoise/Subversion is so picky about everything (IOW, it works as intended) that I'm afraid that if I change the name, everything will get all hosed up.
Am I being unduly paranoid? Should I just go ahead and rename it, or does Tortoise/SVN have some "refactor" ability that will make that a safe operation, or...?
You are not being truly paranoid, once you commit, you have that commit forever, it's worthwhile to take the time to make sure your commit is right. Otherwise, you'll still have to spend that same amount of time to do the "fix" commit.
You probably "saved" through the gui some set of items multiple times, and the "window manager" has an option to not overwrite files by adding (1) and the like. If so, odds are good that only one of the branches is actually under revision control. Do a
svn status
in a few directories to determine if these sub-directories have only been copied in place on your system, have been copied and added on your system, or have been copied, added and committed to the repository.
If they have only been copied in place, discover which "copy" is the best, and move the contents of that copy to the "correct" location, and delete the others. Then svn add whatever is necessary and commit.
If they have been copied and added, discover which "copy" is the best, svn revert everything you do not intend to commit, move the contents of the "best" copy to the correct locations, and delete the unneeded files. Then svn add whatever is necessary and commit.
If they have been copied, added, and commited, then svn delete stuff that's "in the way", svn commit, svn move the right stuff into it's correct location, svn commit, svn delete the other unneeded files, and svn commit.
There are many other variations on how to fix this (some much better than I have demonstrated), but hopefully the above examples will get you thinking along the right paths. My examples involve more steps, to keep things simple.
Related
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.
We have an existing repository on the network accessed via HTTP:.
Should I first import these files to my local machine? I tried importing directories, files, etc., everything is empty in my local folders. It says "success", but nothing ever shows up!
It doesn't make sense to create a repository on my side. But all the tutorials seem to say that, but then I think they're assuming you're starting from nothing.
My experience with Tortoise SVN has mostly been negative. Typically whatever I think I should do turns out to be incorrect, and I end up having to undo, and redo, or lose my work. Once I even managed to corrupt the main repository and it had to be restored from backup.
I absolutely cannot damage this existing repository!
If you're used to CVS or some older version control systems, note that SVN uses the same terms differently. In those, checkout often means lock in exclusive mode.
In SVN checkout will make a copy and automatically manage the revisions and help you merge from multiple sources. You don't need to lock a file, unless it's graphical or some other binary where merging doesn't make sense.
So in TortoiseSVN, you can checkout, and edit the files. The icons on the files will change to indicate their status.
SVN is easy in comparison to git, where the same terms are again redefined and significantly augmented!
I have a large (hundreds of files), horribly disorganized (on the file system that is) Xcode project. I want to move a bunch of files into different folders. I want git to track the move operations, and I want my Xcode project to track the moves as well (just keeping the references intact is enough; I don't need Xcode to rearrange its internal group structure, etc.)
If I drag things around in the Finder, both Xcode and git are in the dark. I have faith that git will figure things out by content when the time comes, but I also notice that there's a difference in the output of git status between doing a git mv and moving the file in the Finder, then adding the deletion and addition operations separately, so I'm assuming there's some difference (even if that difference doesn't end up getting encoded into the content of the commit.) Xcode, on the other hand, is hopeless in the face of this. (You have to manually re-find every single file.)
If I use git mv from the command line, git tracks the move, but I still have to manually reconnect each reference in Xcode (or tear them all out and reimport everything, which is a pain in the ass because many of these files have custom build flags associated with them.)
It appears that there simply isn't a way to cause a file system move from within Xcode.
I've found zerg-xcode and a plug-in for it that claims to sync the file system to mirror the Xcode group structure, but I've not been able to google up anything that goes the other way. I just want a way to move files on the file system and have the two other things (git and Xcode) to keep track of the files across the moves. Is this too much to ask? So far it seems the answer is, "yes".
Yes, I've seen Moving Files into a Real Folder in Xcode I'm asking whether someone's written a script or something that makes this less painful.
Actually, by design, Git doesn't track moves. Git is only about content. If any Git tool tells you there was a move (like git log --follow, it's something that was guessed from content, not from metadata).
So you won't lose information if you move files around with another tool then git add the whole folder.
We have multiple developers working on a single Web Application/Project. For that purposes we use AnkhSVN.
One of the developers made some changes and committed the project. Few days later another developed in the team made some changes and made a commit also.
After that, the first developer's changes disappeared. The second developer's changes overridden the first developer's changes.
How to restore? How to keep both updates?
Please be specific. The resolution of this topic is very important.
Actually you cannot commit changes when you are not up to date. I would guess that the second committer did something bad... So the problem is now to get the two changes to merge "posthumously".
To recover I would try (assuming that I correctly understood what you did; and it is educated speculation, because I havent tried it):
copy the current state (without the .svn-folders!) into a temporary folder - this should be the changes of committer 2 to the initial state
roll back to the revision before the first one committed ("update to revision") - i.e. to the version they both have (probably) started from
copy over the changes from the temporary folder
Update to the revision after the first one committed. This should try to merge the changes, and will possibly bring up some conflicts which you will need to resolve manually (this is probably where number 2 made a mistake).
After this you should have both changes in the working copy.
clear the temporary folder and copy the current state (without .svn folders again)
now we are getting ugly: update to HEAD revision and copy back the changes
Check that you have something that makes sense (compile) and commit.
Remember that you cannot really loose anything unless you corrupt the repo - this is version control after all... :-)
I am working on a project with another developer. We are in the process of a major upgrade with lots of breaking changes. The software we are working on is an AddOn to a product, and we are upgrading to work with a new version of the product. He has checked in some breaking changes that will not run in my environment yet because I am still running on the old version of the product. I have checked in some changes on top of those. Is there any way I can retrieve the code such that it includes only the changes up to the point before the breaking changes and also include only my changes after that in my workspace?
If I had not done a "get latest" I would be OK now because I made the changes on my machine so I would have them. But now I need to "get specific version" to take me back before all the breaking changes and somehow merge only my changesets into my workspace. But there seems to be no way to merge changesets into a workspace, only into another tree. I could select only the files that I touched and get the latest versions of those files, but some of the files contain changes from both my changesets and his changesets (and mine are after his).
So what I really want is a way to merge specific changesets into my workspace (without pciking up all the previous changes) to get back to the state I was in before I did "Get Latest". Is there any way to do that?
Looks like there's no good way to do this. Fortunately, I had another branch that represented the changes I wanted (I had only merged my changes I wanted into it). It didn't feel right to just copy the whole tree over my working tree, so I used WinMerge to identify the files that were different and copied just those files over (after a cursory look to confirm that it was a file that included my changes -- there were a few files generated by Visual Studio that were different just because they were in a different path).
So I guess the general solution would be to create a branch in TFS, merge everything you want into it, get a local copy, then copy the results into your workspace. That does leave a mess in TFS, though (how do you completely remove the dummy branch?) Fortunately the branch I had was one we really wanted to keep (we have a build branch separate from teh development branch).
I'm not really sure if this answers your question, but if you select "Get Specific Version..." then you can select a specific changeset.