I am using Tortoise SVN and Visual SVN Server.
Here is how I am using SVN:
Export Code from Windows7 System and then Copy all code Files to my Fedora System
Make required changes.
Then I Checkout on Windows7 System.
Then Copy All code files from Fedora System to windows7 system.
Then paste in Folder where I checked out.
At this point when I check for modified files. SVN shows me all files as modified, even though they are not modified by me.
Also when I diff unmodified files by me no change is shown, but svn shows that file with red icon.
Could someone please explain the solution this issue?
Note: On Fedora System I am using QT Creator to edit code files. This issue observed with .txt, .cpp, .c files only not with qt ui files.
You can find here how TortoiseSVN finds out if a file is modified.
You should look at the file metadata (date of creation/modification, ownership, etc.)
Edit: If you have issues with end-of-line markers, you can modify SVN behaviour with the svn:eol-style property. See this page for Tortoise configuration.
Related
I just merged a directory and am doing a TortoiseSVN diff to check for changes before committing. I can see from the file explorer that I have modified several files, but I can't see anything from the diff, only the propinfo. It seems I modified svn:mergeinfo while merging, and that is all the diff is showing me.
How do I see the actual files that have changed??? Using Kdiff3 vs TortoiseMerge doesn't make a difference.
TortoiseSVN version 1.9.7
When propinfo is modified, TortoiseSVN apparently only shows this propinfo when diffing a directory, if you use "SVN diff" from the context menu.
You can work around this by using Check for Updates from the context menu rather than SVN diff.
This works because "Check for Updates" appears (?) to be equivalent to the command TortoiseProc.exe /command:diff /path:. /ignoreprops, while "SVN diff" does not pass the ignoreprops flag.
I've run into an issue with patch (version 2.6) and was wondering if anyone else has run into this problem:
System A: Virtual Machine (VBOX) with FC21. diff == 3.3, patch == 2.7.5
Generate a Linux kernel patch for ixgbe driver (updating driver to support new HW)
Orig directory: linux/drivers/net/ethernet/intel/ixgbe
update dir: /home/patches/ixgbe-4.0.3
Patch file generated via diff -Naur <orig> <update> > file.patch
File looks OK. There are changed files as well as "new" file being added to the Orig.
Using BuildRoot (2015.08.01) and their patching setup, the patch executes, and works just fine, the driver builds and the image boots.
System B: Corp Server with RHEL6. diff == 2.8.1, patch == 2.6
Copied the entire Buildroot setup to this machine. Modify directory paths and the build runs OK, up until the patch. Output shows that changed files get updated OK, but any "new" file ends up in the "update dir" path, which doesn't exist in this environment. Verified the /home/xx/yy/zz directory DOES exist, that patch created from the filename in the patch file. Why????
System A works just fine, it puts the "new" file in the correct kernel directory.
Anyone seen this strange behavior before? How can I:
tell diff to use the orig directory?
tell patch to use the orig directory? (Build root handles patching via scripts)
Any assistance would be greatly appreciated. . .
Stephen
TL;DR: to generate the patch, make sure the original and modified directories are side-by-side.
Patches will be applied with -p1, i.e. the first component of the paths will be stripped off. So on the original side, you'll have drivers/net/ethernet/intel/ixgbe/<filename>, but on the patched side, you'll have home/patches/igbe/<filename>. Now it looks like patch 2.6 will take the path at the patched side, which clearly doesn't exist. I'm actually surprised that it does work with later patch versions.
The canonical way to generate patches is to make a copy of the full original source directory, i.e. the entire linux directory, and put that side-by-side with the patched directory. Then you do diff -Naur linux-orig linux-patched from the directory just above. Or, better yet, start from a git-controlled linux directory, make the modification, commit the change, and do git format-patch -1 -o <path-to-buildroot-patches>.
I am extremely new to SVN, I am using SVN on Mac OS terminal. I have a file on my laptop that I want to transfer to my repository on my remote server.
This is what I have done:
I have checked out the repository. It says "checked out revision *".
I have used cd until the folder that I want to insert the file. So at this point I have a path like: (...../src/soln$) so I want to insert the file in the 'soln' folder.
When I try:
svn add ('...../lo.java') (the path to my file on my computer) it says:
('....../src/soln/') is not a working copy
svn import ...../lo.java it brought something weird to the screen
Please help me figure out what I am doing wrong or not doing.
The error indicates that the parent is not yet in svn. Try to svn add each folder above lo.java.
As an example if the repo root is at /path/to/my/repo and your file is in /path/to/my/repo/src/soln/lo.java then you'll not only want to svn add lo.java from inside the soln directory, but you'll also want to svn add /path/to/my/repo/src and then svn add /path/to/my/repo/src/soln before you can perform the svn add lo.java
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.
I have SVN configured in Linux at a different location and I need to check-in a shell script to SVN with executable attribute ON from Windows. I use Bamboo as CI, which checks out sources from SVN and does the periodic build. It throws error that shell script is not executable. (Bamboo run as root).
What is the best way to set the executable permission?
I don't use any SVN client and use eclipse to check-in and check-out. If SVN client is the only, how do I find a version that is compatible with SVN plugin that I use in eclipse.
I had a compatibility problem earlier. When I checked-in a file from Tortoise, I couldn't checkout that file from Eclipse.
svn propset svn:executable "*" someScript
The syntax is propset key value so svn:executable is the key and "*" is the value
someScript is the filename
SVN ignores UNIX file permissions when commiting. The way that you set exec permissions on a file is to change the svn properties for that file. If you are on Windows, the easy way to do this is to install Tortoise SVN. Then after you have committed, use Tortoise to open the repo-browser. Find a file that needs to be executable and right-click it to open properties.
The dialog that appears is the SVN properties dialog. Click New to add a new property, select svn:executable from the dropdown list, and set the property value to *.
That's it. When you click OK, it is committed to the SVN repo. The next time you, or the build machine, do an svn update, that file will have executable permissions on Unix/Linux.