TortoiseSVN 1.93
Thought something was odd when I went to commit some changes, as one of the files I had added earlier was not showing up. One in particular is a .cs file in a class library project. I thought this was odd, so I added a dummy test.txt file and then started a commit again, and even that text file was not in the list of unversioned files.
Usually, if there are unversioned files, I will see them and can add them right from the commit dialog. There doesnt seem to be anything in my ignore list that would prevent these files from showing up. However, if I check for modifications, and choose the "Ignored" checkbox, sure enough, both of those files are in the list, among others.
Whats going on here?
Here is my ignore list:
bin obj debug *.o *.suo *.lo *.la *.al .libs *.so .so.[0-9] *.a
*.pyc *.pyo pycache *.rej ~ ## .#* .*.swp .DS_Store [Tt]humbs.db
Checked the SVN properties on the folder where these files were located, and there was an svn:global-ignores property set to reference the entire folder. Removed that, and opened a commit dialog again and those files were listed. So somehow, I must have got a little too ambitious with setting things to be ignored.
Related
I am new to geb testing. We have two project folders. One of them is a subset of others. During last few days, whenever I check the status of the subset project folder using git shell, lot of closure.class files are showing as changed. But I am changing only the groovy files. I am not sure why this is happening? previously I haven't seen anything like this.
Also lot of class files are showing as untracked files.
The file name look like this.
xxx$_$spock_feature_7_29_closure6.class
We are using IntelliJ IDE.
There are lots of files, I mean class files generated when you try to build using gradlew. As Peter had suggested already, create a .gitignore file and add anything you want to ignore, for instance:
*.log
build
.gradle
.DS_Store
*.ipr
*.iml
*.iws
out
*.pem
gradle.properties
and run the gradlew clean command. You will not see those anymore. Cheers!
I have a linux eclipse project checked into our company svn. Works great.
The project is intended to be cross compiled on Windows.
Untill now, I have simply moved the source files between OSes. However, I thought I'd like to let svn do this for me. Should be simple enough, just checkout the eclipse linux src into the VS project dir, right? Wrong!
The correct source was checked out of svn and it worked fine. But when I tried to check it back in i kept getting "Commit not completed filename remains in conflict" errors. I hadn't even changed anything!
Did a little checking. Turns out the linux src directory is pretty much just the source and headers. On the MSVS side the project directory contains the source and headers but also contains a bunch of files that are used by VS with names like projname.vcproj etc. etc.
So, I did a checkout into a scratch dirextory, .\fred. Checked .\fred back in. No problems. Added a new file to .fred, xxx.xxx. Check in reported:
svn: E200009: Commit failed (details follow):
svn: E200009: 'C:\Projects\fred\xxx.xxx' is not under version control
Makes me wonder about those uncommitted Visual Studio files.
So, are those files my problem? Are they breaking the commit operation?
As an alternate solution I am thinking of adding the VS files to the src dir in svn. If linux/eclipse checks them out I can tell eclipse to ignore them (I think it'll just ignore them for me). Any thoughts or recommendations for this approach?
(BTW, i still had fresh source on the linux side so any thing that got clobbered could be safely restored.)
So here is one solution I have working for the moment. I am not sure how totally stable it is.
Caveat: The project i am using already existed as a MSVS project.
In the MSVS solution dir, rename the source dir (MSVS likes the source dir name to match the solution dir name, so this means the source dir may not be named src) to something uninvolved in the solution, like temp.
SVN checkout the src (eclipse like to call source dirs src).
cd into the source dir. Issue the command:
svn changelist msvs *.cpp *.h
Add *.c if needed. "msvs" is the changelist name. It can be whatever you want ti to be.
This will created a changelist for the checked out directory.
Now, copy the remaining files from the temp directory into your source dir.
When you need to do a checkin, cd into the source dir and issue this command:
svn ci --changelist msvs
Note. You have to be in the src dir for this to work.
is it possible to set a 'rule' that tells TortoiseSVN to automatically resolve conflicts on a specific folder?
ie. we have a shared resources folder - "/shared" that we use to store our latest bin files in. when we do a local build, the local bin files in that folder gets overwritten.
next time we do an svn update on that folder the update should pull the latest bin files from SVN and overwrite the previously locally-built bin files but this will throw a conflict because the files are binary and cannot be merged (and, should not be merged anyway)
we would like to setup a rule that tells tortoise to always "resolve using theirs" on that /shared folder ("svn update -R --accept theirs-full")
There's a SVN misuse here. If the files should not be merged as you said, the directory should be set to ignore all .bin files (svn:ignore). It doesn't make sense keep in version control binary files that are changed frequently causing so much collisions.
In your place, I would delete all .bin files from this folder. If it's really necessary to keep the files versioned, I would create a directory and place these .bin files in there, avoiding frequent changing.
But if you really want to keep the files as they are, I recommend you to write client-side hooks for post-update events. See TortoiseSVN Docs for more information.
I have recently switched to git.
In my previous and first commit since using git, I noticed it also listed the pyc files during the commit. I didn't think anything about it and commited and pushed them.
Now I realize they keep getting updated during the development and its very annoying seeing them in the list. It just produces too much noise.
I did some research and did echo "*.pyc" >> .gitignore in the project directory.
This didn't help though as the pyc files are still being shown. Could it be that because I have previously committed those pyc files I can no longer ignore them? (since they are tracked now and the state has changed again) If so I am damned forever or is there still hope to delete the files in the hindsight from the repository?
Thanks
Just git rm the .pyc files, and make sure your .gitignore is set to ignore them from now on. You are correct that git will not ignore the committed files because they've already been added. If you are keen about not deleting the off the disk, then use git rm --cached to delete the files. That just deletes them from the index without deleting from the disk.
I have added an exclusion to my workspace which is called "dev-machine"
-//depot/DotNetProject/bin/... //dev-machine/bin/...
The bin folder now shows as excluded in p4diff but...
The differences are still showing i.e. diff 1 of 11 and the next and previous arrows are still taking me into those excluded folders.
Am I missing something obvious here?
Did you add the client-spec rule to remove the bin directory after making changes to the directory, and opening files in the directory? Perforce will still consider the files as mapped until you explicitly sync, and even then it'll prevent you from removing the file Perforce knows is open.
If Perforce already thinks the files in the bin directory are open (check with p4 open), your best bet may be to force-sync these files, or revert them, to remove them from your workspace. You'll end up with no files in your bin directory (at least, that Perforce is tracking), so you'll need to rebuild.